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.
Re:Goodbye, Clean Code
by de_watcher on Monday January 13, 2020 @07:14AM
(#22033744)
You can discuss when the rewrite is done, that way it wastes less of your time: you can talk about non-hypothetical existing thing. If the discussion shows that the rewrite is bad then it's his problem: he has to fix or revert.
Plus even the initial rewrite is more time-consuming to do if he doesn't discuss it with the original author beforehand.
Re:Goodbye, Clean Code
by DelightOne on Monday January 13, 2020 @05:50AM
(#22033356)
Should every change be talked over? If not which ones?
If you run scrum, then every ticket should be talked over, and large changes should be discussed. Every change? No. Architectural changes? For sure.
A rewrite of someone else’s code? Most definitely.
Re:Goodbye, Clean Code
by useragent86 on Monday January 13, 2020 @05:32PM
(#22039482)
> 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.
Why is this condescending tone and unfounded assumption acceptable here?
It's like, Well, lookie here, a stranger with a generic opinion! What an amazing opportunity for me to assume specifics and talk down to him! You're welcome!
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.