“What the fuck is this code? I’ve told you 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.

This post is all about the approach to adopt when doing a code review. If you’d like to know what to report, read the full list of what to report in a code review

Anyone can lose their temper, we are human beings, but there’s a real person on the other side of the screen, someone more fragile than you. A more junior developer, perhaps someone who’s new to this, perhaps worried about making a bad impression or even losing his job.

No sorry, there is no justification for 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 bad 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 come up with possible reasons. You remember when you were a junior dev, right? Maybe from your external point of view, you can help understand his own train of thought.
2. If the same mistake has been made multiple times by the same person, ask him why he makes it. Is he convinced his choice is right, or has some issues? If he is convinced, listen to him with an open mind. Be open to the idea that he’s right, or defend your opinion fairly and as an equal.
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 works to the best of their ability. 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’re reviewing their code 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, suggest 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. Never fix the code yourself. Instead, 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 a review.

What truly distinguishes a senior developer from a mid-level one is the ability to communicate with those who are just starting out. Here is a small experiment I conducted with my sister, who is a teacher.

12 Angry Men, Sidney Lumet 1957