5 ms·

> You should not take issue of your work being reverted (for good reasons), like other people should not take issue of "their" code being modified. Better ask f

by jt2190 7y ago

> You should not take issue of your work being reverted (for good reasons), like other people should not take issue of "their" code being modified. Better ask for forgiveness than permission. Changing one developers _working code_ after they’ve invested a significant amount of time into without discussing it with the team first it is to basically heap on a number of unwritten requirements and also decide that the schedule allows for addressing them. If removing repetitive code is a requirement then the team needs to be informed that code will be reviewed for repetition, and introduced to various techniques for spotting and removing repetitive code. The schedule also needs to be adjusted to allow for this additional work. And if the rewritten code is so superior than perhaps there needs to be a discussion about whether there should even be a team, or whether the other people should be let go and all work assigned to the developer who can do the work “properly” the first time. After all, what’s the point in having one developer’s work constantly rewritten by another?

habitue 7y ago
> 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
celticmusic 7y ago
So relevant. I had an experience this year where I was working with another developer. This guy would legit walk behind me rewriting everything I did. To put this into perspective, I've been doing this work for over 20 years this guy came out of a bootcamp last year. But it wasn't even that this guy was rewriting things, it's that he was constantly breaking things as a result. Imagine every fucking day you come in and something's broken that was working last week and you're like "wut?!? that was working, what happened?!". This was a contract with a guy I'd been doing work with for years. The other developer was from another country and was one of his first employees. The straw for me was when he rewrote my small testing framework. I spent about a day trying to standup a unit testing library in the framework they were using and finally decided it would be quicker to just write a simple testing mechanism + runner, which took me a few hours to do. I come in the next week, and this guy had taken that idea, and then just rewrote the entire thing. I called the owner up and just straight up told him he's paid me to do nothing. Literally every single line of code I've written has been rewritten by this guy, only in a shitty, buggy manner. That was 2 months in, and at that point I had tried talking to the guy about it and I was done. Fast forward to today and that system STILL isn't working. It would've taken me 4 weeks at MOST to build and stabilize. We're coming up close to a year now. I'm still good friends with the owner so I ran cloc over the codebase. It went from 3k LoC to 21k LoC. The owner finally admitted to me that he's going to be paying for employing that developer for a very long time. So while I understand the sentiment about not 'owning' code and would have agreed with it before this experience, the trust issue with respect to rewriting is waaaaay bigger than that. I told the owner that this developer should never have been let near a code base with any ability to make decisions on their own. They needed years of mentorship. I literally disagree with every single decision they make. It's mystifying. It's almost like the guy always asks me my opinion and then does the complete opposite, only that's not the case.
- latchkey 7y ago
  You sound really angry about it and you've hung onto it for quite some time. A good friend of mine used to tell me 'who cares?' when I would rant on about things just like you just did. It is honestly startling to hear that in response to a rant. If you answer 'i care!', then that is exactly the problem. Let it go, it isn't worth it. At the end of the day, I'd say this is your problem to work on. You didn't step back, slow down, forget about the code, and mentor the other developer well enough when you were there. That is kind of exactly what the OP is saying in his post. (Side note: I've been you many many times and it only hurt me in my career. I actively work against it now and things have been much better.)
tragic 7y ago
> If removing repetitive code is a requirement then the team needs to be informed that code will be reviewed for repetition, and introduced to various techniques for spotting and removing repetitive code. Things like this are never requirements, at least in the conventional sense of 'things the stakeholders ask for the software to do'. Nor should they be: it's our job as professionals to know how to do our work. I don't want a PM or sales rep worrying about the Liskov substitution principle (unless I'm working for code climate or something): it's a waste of their time. Code cleanliness should make future changes easier. Of course, some 'cleaning' expeditions do the opposite, so there should still be code review etc.

by jt2190 7y ago

habitue 7y ago

> 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

celticmusic 7y ago

So relevant. I had an experience this year where I was working with another developer. This guy would legit walk behind me rewriting everything I did. To put this into perspective, I've been doing this work for over 20 years this guy came out of a bootcamp last year. But it wasn't even that this guy was rewriting things, it's that he was constantly breaking things as a result. Imagine every fucking day you come in and something's broken that was working last week and you're like "wut?!? that was working, what happened?!". This was a contract with a guy I'd been doing work with for years. The other developer was from another country and was one of his first employees. The straw for me was when he rewrote my small testing framework. I spent about a day trying to standup a unit testing library in the framework they were using and finally decided it would be quicker to just write a simple testing mechanism + runner, which took me a few hours to do. I come in the next week, and this guy had taken that idea, and then just rewrote the entire thing. I called the owner up and just straight up told him he's paid me to do nothing. Literally every single line of code I've written has been rewritten by this guy, only in a shitty, buggy manner. That was 2 months in, and at that point I had tried talking to the guy about it and I was done. Fast forward to today and that system STILL isn't working. It would've taken me 4 weeks at MOST to build and stabilize. We're coming up close to a year now. I'm still good friends with the owner so I ran cloc over the codebase. It went from 3k LoC to 21k LoC. The owner finally admitted to me that he's going to be paying for employing that developer for a very long time. So while I understand the sentiment about not 'owning' code and would have agreed with it before this experience, the trust issue with respect to rewriting is waaaaay bigger than that. I told the owner that this developer should never have been let near a code base with any ability to make decisions on their own. They needed years of mentorship. I literally disagree with every single decision they make. It's mystifying. It's almost like the guy always asks me my opinion and then does the complete opposite, only that's not the case.

latchkey 7y ago
You sound really angry about it and you've hung onto it for quite some time. A good friend of mine used to tell me 'who cares?' when I would rant on about things just like you just did. It is honestly startling to hear that in response to a rant. If you answer 'i care!', then that is exactly the problem. Let it go, it isn't worth it. At the end of the day, I'd say this is your problem to work on. You didn't step back, slow down, forget about the code, and mentor the other developer well enough when you were there. That is kind of exactly what the OP is saying in his post. (Side note: I've been you many many times and it only hurt me in my career. I actively work against it now and things have been much better.)

tragic 7y ago

> If removing repetitive code is a requirement then the team needs to be informed that code will be reviewed for repetition, and introduced to various techniques for spotting and removing repetitive code. Things like this are never requirements, at least in the conventional sense of 'things the stakeholders ask for the software to do'. Nor should they be: it's our job as professionals to know how to do our work. I don't want a PM or sales rep worrying about the Liskov substitution principle (unless I'm working for code climate or something): it's a waste of their time. Code cleanliness should make future changes easier. Of course, some 'cleaning' expeditions do the opposite, so there should still be code review etc.