5 ms·

I need to disagree with you, I've been in a few positions where one engineer suddenly decided to rewrite parts of the code base without any input from other eng

I need to disagree with you, I've been in a few positions where one engineer suddenly decided to rewrite parts of the code base without any input from other engineers. It's a huge blow to team morale, and it gave me a fear of writing code in this team. Every time I wrote a piece of code, I wondered how long it would be there for, I understand that code evolves, but seeing your code being rewritten after a week is no fun, and it's a huge blow to your confidence as well. I understand that code needs to be rewritten, because of requirement changes, or different understanding of the original problem, but talk about it, bring it to the attention of the team as to why you feel we need to rewrite. Make sure that the team understands why, and sees the value in it. Just rewriting code on your own is a big no for me, and to me, breaks the trust that we had.

temac 7y ago
> seeing your code being rewritten after a week is no fun, and it's a huge blow to your confidence as well. The people doing the rewrite benefit from your work though. They might would have done the initial writing "worse" than you did. It is good to have fresh views. I agree it is good to communicate, too.
- woutr_be 7y ago
  The main thing is indeed the communication, it would solve most issues.
kazinator 7y ago
> Every time I wrote a piece of code, I wondered how long it would be there for. The fix for that sort of thing is to have a satisfying, enduring side project where you're the boss: nothing is upstreamed that you don't like. Then you can stop caring if your code at work gets replaced, and how fast.
- woutr_be 7y ago
  I care more about the way it gets replaced. I constantly learn from my code being replaced, and replacing code myself. However I doubt anyone liking code being pushed onto them. That’s how I feel when someone decides to rewrite code without anyone’s knowledge. They already did the work, so they’re expecting it to be merged in.
- useragent86 7y ago
  Reading this made me smile. TXR is obviously that for you, and I wish all software were developed with such care.
tsukurimashou 7y ago
I know that programmers are humans but I think paying too much attention to people's feeling is what is dragging the IT industry down, if you have self esteem issues go see a shrink
- woutr_be 7y ago
  It’s not about personal feelings or self esteem, it’s about trust within the team, and confidence that when you do something the team sticks to it. When a rewrite is required, the team talks about it and then acts.
bjourne 7y ago
> Every time I wrote a piece of code, I wondered how long it would be there for, I understand that code evolves, but seeing your code being rewritten after a week is no fun, and it's a huge blow to your confidence as well. Here's some tough love. If people frequently rewrite code that you write it is because they are stronger developers than you are. You, the junior developer, can either sulk about it and feel miserable or realize what an amazing opportunity you have to improve. Swallow your pride and approach the person who rewrote your code: "Hey, I noticed that you rewrote the code I wrote last week. Mind telling me what was wrong with it so that I can learn from you?" If the person answers "No" or "I don't have time" that person is an asshole and you are in the wrong place. But if the person answers "Sure! Let's schedule a meeting in a conference room with a whiteboard this afternoon and I'll explain what was wrong with it!" then you are in a great spot! > Just rewriting code on your own is a big no for me, and to me, breaks the trust that we had. Not for me. I trust my teammates judgement. They know when it's a good idea to rewrite my code and when it's not. No point wasting time holding meetings and bikeshedding over minutiae over work that can be done in a few hours. 9 times out of 10 they will do the right call. 1 time out of 10 they won't and we revert - no damage done.
- woutr_be 7y ago
  I think you’re missing the point as to why I might lose confidence. I’m fine with people being better than me, especially when they explain why they did certain things. But we work as a team, that means that before we do work, we agree on one thing. If suddenly an engineer decides a week later he wants to do something else, then that’s not cool. Even if he has a valid reason for it. Instead you talk to the team, and agree to change. Again, there’s a reason why we work in teams, and not as individuals. I trust my teammates too, but rewriting code without any discussion breaks that trust for me.
  - DelightOne 7y ago
    Should every change be talked over? If not which ones?
    - 7y ago

temac 7y ago

> seeing your code being rewritten after a week is no fun, and it's a huge blow to your confidence as well. The people doing the rewrite benefit from your work though. They might would have done the initial writing "worse" than you did. It is good to have fresh views. I agree it is good to communicate, too.

woutr_be 7y ago
The main thing is indeed the communication, it would solve most issues.

kazinator 7y ago

> Every time I wrote a piece of code, I wondered how long it would be there for. The fix for that sort of thing is to have a satisfying, enduring side project where you're the boss: nothing is upstreamed that you don't like. Then you can stop caring if your code at work gets replaced, and how fast.

woutr_be 7y ago
I care more about the way it gets replaced. I constantly learn from my code being replaced, and replacing code myself. However I doubt anyone liking code being pushed onto them. That’s how I feel when someone decides to rewrite code without anyone’s knowledge. They already did the work, so they’re expecting it to be merged in.
useragent86 7y ago
Reading this made me smile. TXR is obviously that for you, and I wish all software were developed with such care.

tsukurimashou 7y ago

I know that programmers are humans but I think paying too much attention to people's feeling is what is dragging the IT industry down, if you have self esteem issues go see a shrink

woutr_be 7y ago
It’s not about personal feelings or self esteem, it’s about trust within the team, and confidence that when you do something the team sticks to it. When a rewrite is required, the team talks about it and then acts.

bjourne 7y ago

> Every time I wrote a piece of code, I wondered how long it would be there for, I understand that code evolves, but seeing your code being rewritten after a week is no fun, and it's a huge blow to your confidence as well. Here's some tough love. If people frequently rewrite code that you write it is because they are stronger developers than you are. You, the junior developer, can either sulk about it and feel miserable or realize what an amazing opportunity you have to improve. Swallow your pride and approach the person who rewrote your code: "Hey, I noticed that you rewrote the code I wrote last week. Mind telling me what was wrong with it so that I can learn from you?" If the person answers "No" or "I don't have time" that person is an asshole and you are in the wrong place. But if the person answers "Sure! Let's schedule a meeting in a conference room with a whiteboard this afternoon and I'll explain what was wrong with it!" then you are in a great spot! > Just rewriting code on your own is a big no for me, and to me, breaks the trust that we had. Not for me. I trust my teammates judgement. They know when it's a good idea to rewrite my code and when it's not. No point wasting time holding meetings and bikeshedding over minutiae over work that can be done in a few hours. 9 times out of 10 they will do the right call. 1 time out of 10 they won't and we revert - no damage done.

woutr_be 7y ago
I think you’re missing the point as to why I might lose confidence. I’m fine with people being better than me, especially when they explain why they did certain things. But we work as a team, that means that before we do work, we agree on one thing. If suddenly an engineer decides a week later he wants to do something else, then that’s not cool. Even if he has a valid reason for it. Instead you talk to the team, and agree to change. Again, there’s a reason why we work in teams, and not as individuals. I trust my teammates too, but rewriting code without any discussion breaks that trust for me.
- DelightOne 7y ago
  Should every change be talked over? If not which ones?
  - 7y ago