“What the fuck code is this? I’ve said a thousand times to use strict operators, you don’t care about the quality of the project!” If you find yourself thinking things like that when doing code reviews this post is for you.

It can happen to anyone to lose temper, we are human beings, but on the other side of the screen there is someone more fragile than you. A more junior developer, perhaps a first-time developer, perhaps worried about making a bad impression or even losing his job.

No I’m sorry, there is no justification in using your position of strength to bully other people. Not even for an infinite loop or a global variable.

So here are 10 tips for dealing with a failed code review.

1. Before you say it’s wrong, ask why he did it that way. Maybe there is a reason or an issue that you don’t understand. If the developer can’t answer, use your experience to make hypotheses. Do you remember when you were Junior, right? Maybe from your external point of view, you can help understand his flow of reasoning.
2. If the same mistake has been made multiple times by the same person, ask him why he makes it. Is he convinced of the goodness of his choice or has some issues? If he is convinced, listen to him without prejudice. Be open to the idea that he’s right, or defend your opinion loyally and equally.
3. Always talk about code, don’t judge the person. (This doesn’t even need to be said)
4. There is no point in reporting errors if you are not able to propose better solutions and explain them clearly.
5. Remember that everyone does their best according to their possibilities. If this isn’t enough, it’s your responsibility to teach them to do better. If you don’t succeed, the failure is yours alone.
6. Don’t expect a junior developer to write code like yours. There’s a reason why you code review him and not the other way round. Good enough is enough.
7. If after the first back and forth you have the impression that he hasn’t understood, invite him to a one-to-one call. Endless discussions in writing increase misunderstandings and chaos.
8. The customer does not care about implementation details and tends to get nervous if he thinks the situation is not under control. Resolve the most sensitive issues privately (see point 7).
9. Don’t fix the code yourself, never. Rather propose a pair programming session. This will make the team grow, and you too.
10. Ask yourself for honest feedback on your work and be open to criticism. Everyone needs review

12 Angry Men, Sidney Lumet 1957