[treebot]

You should 100% talk to the original author before rewriting though. Not doing so communicates that you think you know better than them, so much better than them that you don't even need to talk to them to understand why they wrote it the way they did, and the tradeoffs. This is very arrogant and would most likely bother the original developer, which is bad for team dynamics.

[muzani]

I disagree. Most of the time I'm intrigued by the changes someone makes to my code. It's like a musician getting their song covered. There's a creative interpretation, often something I didn't see.

This one was a bad example. But past 5 or so years of experience, when someone has experience with other languages and coding styles, it's more interesting and I often learn a lot from them.

[zugi]

Maybe we're envisioning different scenarios here. If someone just committed code yesterday and is still working on it, absolutely discuss with them first. I'm imagining a scenario where someone comes across duplicated code months or years later. What if the original author is gone? Code needs to be clear enough to understand after the original author is gone.

Change for change's sake may be bad for team dynamics. But if the change is one that everyone agrees is for the better, no one should be offended by the improvement.

[jamil7]

I mostly agree with you but I've found that in certain (smaller) teams with a high level of trust and experience it can be fine to do this without a heads up.