If you're giving soul-crushing feedback and not enjoying it like the OP, one problem could be that perhaps you're not providing the developer with enough detail on the task at hand. Communication isn't easy.
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!
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!