Completely understand the frustration here. Mistakes happen, even competent people sincerely trying to do a good job can overlook things, etc. But if it’s a pattern of just copying and pasting code without really even trying to understand what it does, that’s a big problem that needs to be addressed. And frankly they should feel embarrassed if it happens more than once or twice.
OTOH, delivering criticism in a way that winds up productive for all involved is difficult at best, and the outcome depends on the junior as much as it does the senior. What good is being right if it ultimately just alienates you from your team? Tough situation for sure, and one of the many reasons it’s so important to hire carefully (which is itself a whole huge can of worms too!).
Can you simply ask them to walk through their submission line by line with you, explaining what it’s doing? If you’ve never asked that before it might come across as a strange request, but if you phrase it well it’s possible this causes them to notice their poor understanding without you ever seeming to point it out.
Can you simply ask them to walk through their submission line by line with you, explaining what it’s doing?
This. Code reviews, especially with junior devs, should always be done as a conversation. It’s an opportunity to learn (from both sides), not just a a bunch of “bad implementation. rewrite” thrown in the PR.
Completely agree! It’s SO much easier to lighten the mood and keep things upbeat and productive in an actual conversation vs. just text-based feedback. For example it makes it easy to throw in self-deprecating anecdotes of your own when discussing mistakes / needed changes, which can really help put juniors at ease. It’s just worlds better in >90% of scenarios.
Completely understand the frustration here. Mistakes happen, even competent people sincerely trying to do a good job can overlook things, etc. But if it’s a pattern of just copying and pasting code without really even trying to understand what it does, that’s a big problem that needs to be addressed. And frankly they should feel embarrassed if it happens more than once or twice.
OTOH, delivering criticism in a way that winds up productive for all involved is difficult at best, and the outcome depends on the junior as much as it does the senior. What good is being right if it ultimately just alienates you from your team? Tough situation for sure, and one of the many reasons it’s so important to hire carefully (which is itself a whole huge can of worms too!).
Can you simply ask them to walk through their submission line by line with you, explaining what it’s doing? If you’ve never asked that before it might come across as a strange request, but if you phrase it well it’s possible this causes them to notice their poor understanding without you ever seeming to point it out.
This. Code reviews, especially with junior devs, should always be done as a conversation. It’s an opportunity to learn (from both sides), not just a a bunch of “bad implementation. rewrite” thrown in the PR.
Completely agree! It’s SO much easier to lighten the mood and keep things upbeat and productive in an actual conversation vs. just text-based feedback. For example it makes it easy to throw in self-deprecating anecdotes of your own when discussing mistakes / needed changes, which can really help put juniors at ease. It’s just worlds better in >90% of scenarios.