Code Review is one of the most important steps in the process of creating clear and high quality software. What do you define as your goal when, as a software developer, you start to verify the code written by other team members? Is it bug hunting? Maybe quality control? Or perhaps learning? Have you ever thought about code review as one of the communication channels and possible ways to build relationships in your work team?

During my conversations with other programmers, especially those who are just starting their programming career, I often hear them talking about stress related to code review. For them, code review is seen as a critique which looks for mistakes in their work. Of course they see the value behind the verification of their code by the people who are not its authors. They also realize that this is a chance for them to learn and improve their qualifications.

At the same time, the code review reminds them of school exams and assessment by other people. These situations are accompanied by the thought that it’s not only the code, but also their professional judgment that is being evaluated.

Humanity in code review

Let’s be honest – code review is a type of feedback and evaluation. Exactly like in any other type of communication, we have the sender and the receiver. We provide information and we expect some effects. But the effect can not just be well-written code, but also a well-coordinated team satisfied with their work.

How to achieve it? There are 5 simple steps:

Do not talk to the author

When you are directing a message to the author, it becomes more personal. You stop evaluating only the code. You’re starting to judge the person. You point out their mistakes, which they may perceive as undermining their competence. Please note that when you write “typo” it sounds less friendly than writing “person => person”. It is better to write “maybe we can change the name of this function” than “change the name of this function”.

As I mentioned earlier, one of the main concerns of people asking for a code review is precisely that they are the object of evaluation. And you do this when you are directing a message to the second-person singular – you are talking about the person, not about the code.

Instead of ordering, suggest and request

This is a great way to show your respect to the author of the code. Then you do not assume that your way is better than theirs or their approach is wrong. When your message looks more like a suggestion or question it sounds more tactful, and you and the recipient are then equal partners of the conversation.

“Rename this function” sounds like an order. You become a supervisor, not a partner. You also suggest that the author did something wrong and it is obvious, with no opportunity for any discussion. By changing this comment to the form of the question: “Could we change the name of this function?”, you give the author space to answer and justify their choice.

Also, notice that by giving someone an order you take away their autonomy and the authorship of their code. It’s not their choice anymore, it’s yours. If the author had a reason to write the code in a certain way and would like to defend it, then the conversation may take the form of an argument,

For example, “I do not want to change the name of this function, because it complies with our convention.” We will reply to the form of the question “I used this name because in my opinion it complies with our convention. Can you justify your suggestion? “

Give a reason

When you are suggesting a change, also add justification for your proposal. Why should we change anything? Of course, this is not about things like a typo or a missing comma. But if you propose a change in the approach or the solution, please also write why you think it will be better. Is it related to optimization or an accepted convention?

You can also provide links to some articles or documentation. Show that your suggestion is not only your personal opinion. Maybe the author does not know something, maybe he did not take something into account.

Come, call, talk

If you do not understand  or if you have doubts or you suggest a very big change, you don’t have to limit yourself to a comment. If the author is sitting nearby, go to them. If there is a bigger distance between you – call. During a verbal conversation it’s easier to explain everything and have a proper conversation. You will have greater confidence that you understand each other and achieve the expected code review effect.

Praise

Have you ever praised anyone during code review? If not, it’s really worth trying. For the interns or juniors it would be nice to write at least that their code is getting better and better. You can praise them for an interesting solution or code readability. Think about how you would feel if another team member praised your work. Wouldn’t it be nice to know that you are doing something right?

Our culture is more focused on looking for things to improve. That’s why you rarely hear the words of appreciation. And these words are really valuable for teamwork. Hearing words of appreciation for their own efforts can make people feel valuable members of the group, which builds their motivation and loyalty. Believe me – praise is not something difficult or which requires a lot of effort. However, its effects can be amazing.

Recap

Sometimes simple changes can bring  great results. Look at the code review not only as a method to look for errors, but also as another channel of communication with other team members. As with any communication method  our information is essential – it’s obvious. But also the manner in which we provide information is very important. It is necessary for effective work and achieving great goals.