Hacker News Reader

Comment by zugi | Hacker News Reader

When we don’t feel confident in our code, it is tempting to attach our sense of self-worth and professional pride to something that can be measured.

I don't think assuming people who disagree with you lack confidence and are "compensating" is an effective way to reach an audience.

Rewriting your teammate’s code

There should be no such thing as "your teammates code", there is only your team's code. If the changes were improvements they should be welcomed by the team, if they worsen the code they should be unwelcomed - independent of who first authored the lines.

There is absolutely judgement involved in refactoring, code replication, and choosing the right abstraction. But this article doesn't offer much wisdom that helps with those decisions.

View on HN

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.

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.

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.

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.

To be honest, i found these values touted, to be the signal of the worst kind of subjective code, leading to endless "battles" between subjective "better" code styles and bitter endless "but mine is more logic"-debates where the subjectiveness of ones opinion is not even perceived.

I had programers on lousy toolchains argue for the 9000 codeline one-file copy paste monolith, because it was "objectively" easier to debug.

There is always a teammates code, who will be different.

You might be projecting. That read like the authors personal experience, one that you might reasonably suspect others have shared.

Reply on news.ycombinator.com