6 Principles Of Code Reviews Without Tears

I remember when I just started and my code was burned during a code review. It felt so bitter, I wanted to cry.

I remember how I pointed out at a few things in a code review of my colleague that would help him not only to improve the code, but to improve his approach to writing code in general, and I saw him taking it so personal that he almost bursted in crying.

I remember making so stupid remarks about code that even now when I recall it, I want to cry.

Years have passed and my code reviews got less dramatic. Mostly due to a few principles that I have adopted that save me quite a few tears.

1. This is very banal, but what many people often tend to forget, especially during tough debates around code and programming principles — always to be polite. Regardless subject, how wrong and emotional you counter part can get, it is not worth an argument if one of you cannot remain polite and respectful. Moreover, when you treat people with respect, they tend to lower their guards and listen to your arguments more carefully.
2. Don’t take things personal. Things can feel soar when someone criticise your code. However, you should remember that a code review is not about how good you are as developer. It is not even how good your code is. It is about you joining the forces with your colleagues in order to find the best solution to a problem. Only by accepting this as the ultimate goal of a code review, you can stop feeling offended and start improving as developer. As a matter of fact, I learned the most from those developers who criticised my code the harshest.
3. In the ideal world, nobody takes code reviews personal. In the real world, people do it more often than not. Remember who you are dealing with. Some people can take more criticism than the other, and you should consider that when you review a code. If you see that a person is open to criticism, that he/she is genuinely looking for the best solution, and ways to improve himself as developer, you can give him more pepper than the other. If you see that a person is very sensitive to criticism, often it is better to leave it to his psychiatrist, and, perhaps, correct only egregious mistakes.
4. There are often objective goods and bads in software development. However, more often the problems that people argue about during code reviews are a matter of personal preferences and coding style. Respect them, tolerate differences, and be more liberal in your approach to people’s code. And learn how to distinguish a mistake from a different approach from yours. It could be hard. And if you hesitate, ask your counter-part to help you to understand it. Maybe his approach is not so bad in the end.
5. My ex employer was always saying “Software development is about communication”. And he was 100% right! There is no great product that was built single-handed. I will add here that communication is also the most difficult about software development. Everyone can write a code that a computer can understand. Only a few can explain this code to a human. And this is what distinguishes a bad developer from a good developer — an ability to explain yourself to computer as well as to other humans. Code review is the time when you can get together with your colleagues and make sure that you all understand what you are doing and why. So explain yourself, ask questions, and walk an extra mile to make sure that you understand each other.
6. Code review is not only about finding problems in code. It is also about learning and discovering new things. And if you have learned something new, or see that the chosen solution is very good — do not hesitate to the author about it. It will enhance your relationship and help to see that you are here not only to burn the code, but to learn, and to appreciate others work.

There are also a few tricks that I adapted that help to make code reviews less painful:

• start criticism with a compliment, say first something good about the code, then a bitter pill is sweeter to swallow
• use smiles when writing criticism comments, it helps people to see you more friendly, and less hostile
• If there is an argument about some “grey zone” like code formatting, or conventions, and you could have reached a compromise on it — document it, and next time you have the same discussion with someone else, you can point to this document as “the official agreement” on this subject, reducing the time you spend on justifying yourself