I ruin developers’ lives with my code reviews and I'm sorry

I have been mentoring junior developers for about 10 years, and some more senior ones for the last few years. My ego is more attuned to getting things done than tearing up people's work. The following works really well for me:

1. Never insult people's work, it's counter-productive. (Unless see number 9) 2. Nitpick on convention/style, not implementation, unless the implementation is infeasible. Convention and style will quickly become rote. This forces new developers to pay more attention. 3. If it works as intended and has meaningful tests, MERGE IT. Congratulate them :rocket:! 4. Point out logical pitfalls/caveats by asking "what would happen if". Asking questions starting with "why" triggers people and puts them on the defensive. That's your EQ lesson for today. 5. Through code-review, you can identify a lot of little problems and suggest articles to read that would help the person grow. Examples: misunderstanding async/await vs. thenable in JS. Parallel programming in R/Py. These are distinct, language specific (R has sessions/multicore, Py has the GIL) pieces of knowledge that people can learn easily with a tiny bit of guidance. 5. If you're a better programmer - write the first 1000 lines so that they can fill in the next 10,000 (credit: don't remember, someone tell me?) 6. Even junior developers can get a surprisingly challenging task done if you give them hints (point form) about how you might approach it. 7. Do code reviews in-person (1-1) or if you are tactful with your feedback and have encouraged an environment where making mistakes is acceptable - in a group, that way everyone learns! This is the management version of the DRY principle. 8. One of the biggest problems I see with new developers is "how do I break this problem into smaller pieces". Discuss potential approaches BEFORE the PR. Not after. 9. Fire people that are consistently lazy. When you manage people for a long time it easy to see the difference between someone that needs training and someone that is lazy. You can help a someone that wants to learn, but you can't motivate someone to be interested in something that they aren't already. 10. Cultural differences can make people less likely to speak up when they are stuck - check in with your team!

Or he's just lazy.

It's way harder to build up the people you work with than tear them down. The key ingredients tp the former are patience and empathy. And those qualities are lacking in many managers.

Also, aggressive, opinionated people are often perceived as more intelligent than their more reserved peers. You'd think that the snowmen can't get snowed, but the type of person the author describes seems to be just as vulnerable to the misdirection as others.

Another possible reason could be that they know it’s temporary. A lot of startup code gets rewritten at least once in the first 5 years, there is some art to knowing what code might stick around and be worth the effort to do well, and what you should just bang out fast and move on.

It sounds like it’s possible you haven’t been able to have a conversation with your colleagues about their choices, which might be worth having candidly if you can find the opportunity to do so. If it is ignorance or negligence better to know and decide how you want to proceed if that makes sense.