4 ms·

> Changing one developers _working code_ after they’ve invested a significant amount of time How much time they invested is irrelevant. There are lots of times

> Changing one developers _working code_ after they’ve invested a significant amount of time How much time they invested is irrelevant. There are lots of times where someone is wrestling with something for so long they just want to get it done and don't want to look at it anymore. Many times it's trivial for someone fresh to tidy it up > If removing repetitive code is a requirement then the team needs to be informed that code will be reviewed for repetition This focus on "requirements" is only really trotted out when someone doesn't like someone changing their code and is looking for a defense. In reality, coding is super subjective, there are dozens of aesthetic judgement calls everyone has to make. Saying something "wasn't a requirement" basically means "fuck off I don't like you touching my code". There's no way to codify concrete requirements for handling every possible way code can be improved. If devs are throwing requirements at each other, that's a culture problem, not a spec problem

roenxi 7y ago
> How much time they invested is irrelevant. That is a central point to gp's argument though. The amount of time does matter, because it affects the schedule and hence triggers management decisions. > ... aesthetic judgement calls everyone has to make. Saying something "wasn't a requirement" basically means "fuck off I don't like you touching my code". If you believe that then you really shouldn't be tidying up other people's code. Why are you making people unhappy over something that you think is an aesthetic judgement call? Let them be happy.
jt2190 7y ago
> There's no way to codify concrete requirements for handling every possible way code can be improved. If the change can’t be codified, then it calls into question why the change needs to happen at all. Assuming that there is some improvement that can be justified, then explain it to the team, and have the team start reviewing for it. By not going through the process of explaining the improvement to the team, it signals that the team can’t be trusted to learn and improve code on their own. Again, if that’s the case, a conversation needs to happen about whether there should be a team at all.
- kortilla 7y ago
  If you don’t trust someone to change your code to make small improvements, it sounds like you have a trust problem, not the other way around. Working on a software project as a large team is like growing a garden, not building a house. Just because someone planted a hedge doesn’t mean it can’t be improved by pruning it.
  - blub 7y ago
    Trust would allow that the code is modified in the first place, but then a code review needs to happen anyway to ensure that at least one more person is aware of the change and as a sanity check that the change makes sense.
- habitue 7y ago
  > If the change can’t be codified, then it calls into question why the change needs to happen at all. No, there are lots of things that are difficult to codify but are very valuable. If you look at law and policy you'll find plenty of examples. This is akin to saying "If I can't formalize it mathematically, it doesn't exist" which is obviously false Additionally, there's the category of things which are maybe in principle codifiable as requirements, but are tedious to specify. I would definitely put aesthetic judgements about code in this bucket. It's much simpler if you say something like "and the developers will use their best judgement on how to write clean maintainable code" and be done with it

roenxi 7y ago

> How much time they invested is irrelevant. That is a central point to gp's argument though. The amount of time does matter, because it affects the schedule and hence triggers management decisions. > ... aesthetic judgement calls everyone has to make. Saying something "wasn't a requirement" basically means "fuck off I don't like you touching my code". If you believe that then you really shouldn't be tidying up other people's code. Why are you making people unhappy over something that you think is an aesthetic judgement call? Let them be happy.

jt2190 7y ago

> There's no way to codify concrete requirements for handling every possible way code can be improved. If the change can’t be codified, then it calls into question why the change needs to happen at all. Assuming that there is some improvement that can be justified, then explain it to the team, and have the team start reviewing for it. By not going through the process of explaining the improvement to the team, it signals that the team can’t be trusted to learn and improve code on their own. Again, if that’s the case, a conversation needs to happen about whether there should be a team at all.

kortilla 7y ago
If you don’t trust someone to change your code to make small improvements, it sounds like you have a trust problem, not the other way around. Working on a software project as a large team is like growing a garden, not building a house. Just because someone planted a hedge doesn’t mean it can’t be improved by pruning it.
- blub 7y ago
  Trust would allow that the code is modified in the first place, but then a code review needs to happen anyway to ensure that at least one more person is aware of the change and as a sanity check that the change makes sense.
habitue 7y ago
> If the change can’t be codified, then it calls into question why the change needs to happen at all. No, there are lots of things that are difficult to codify but are very valuable. If you look at law and policy you'll find plenty of examples. This is akin to saying "If I can't formalize it mathematically, it doesn't exist" which is obviously false Additionally, there's the category of things which are maybe in principle codifiable as requirements, but are tedious to specify. I would definitely put aesthetic judgements about code in this bucket. It's much simpler if you say something like "and the developers will use their best judgement on how to write clean maintainable code" and be done with it