Code reviews are used to improve code quality and benefit from positive effects on team and company culture. On the internet we can find a wealth of material regarding different aspects of it like how much time to review, how many lines of code to read, checklists to make sure every code-wise topic is covered…
In this post, I’d like to focus in one important part of this process. The human one. Since we’re giving feedback about our peers work, I think it’s important enough to spend some time talking about how to do it in the most assertive way possible, in order to reduce not only potential code-related problems but also people ones too.
Be problem-focused and specific
Instead of telling someone what he has to/should do, explain why. Let’s say your comment was “You need to use the veryGood function, not the veryBad one”. This comment assumes everyone involved in the project shares your level of knowledge about it. Be clear about what the actual problem is and structure your feedback around it, so you will be not only helping to fix this specific issue but also contributing to grow the knowledge and independence of your teammates.
Have always in consideration: the more specific you can make your feedback, the more actionable it will be.
Focus on the situation, not the individual
Let’s explain it by using an example: One of your colleagues creates a pull request (PR) and there is no description. To make everything worse, there is only a huge commit without a message and a non-descriptive title. You can attack him, because this is a “known” bad practice, and most likely engage in a pointless ego-battle which only affects the team in a negative way. The other option is discussing the situation itself, rather than just providing your personal opinion about it. This will show you’re more interested in fixing the problem rather than blaming anyone. Impartial observations prove to be more useful.
Give praise and recognition
We are always harder on the code of everyone else than on ours. Weaving some positives among the negatives or simply complimenting when it’s deserved can be a good way to keep everyone motivated and inspire the ones with less technical knowledge to grow.
One example could be a simple “I love what you did here. However, we’ve to take care of this other part because…”. This way we can fight the frustration of only receiving critics about our code, which will go in favor of overall motivation knowing only certain aspects of their work need attention.
Respect for the person’s dignity is the root of constructive criticism. Choose words carefully and try to avoid displaying negative emotions such as anger, sarcasm or disappointment. Select those that do not put the receiver on the defensive. Use messages like “I’ve noticed” or “I’m concerned about” rather than “you” messages, like “you always” or “you never”.
Be careful with the gif you want to put in your comment, they can easily lead to misinterpretation or show negative emotions (as commented before). This can send a mixed message, confusing or even making the recipient feel humiliated.
Learn to listen
Give a chance to respond, so you show that you are prepared to listen to other people’s concerns and interpretations. Expressing their ideas are making them, most likely, become part of the solution.
It may look easier and quicker to just answer a comment in the PR face-to-face instead of taking some time for organizing your ideas and writing it down. This information is not visible for the rest of the team, which can be expecting a reply from you on the PR in order to proceed with it or just need to have more info about it. Transparency can always go in favor of knowledge sharing and technical growth.
Since we are providing feedback about the work made by another person, we should keep as respectful and assertive as possible. Engaging in negative emotions can led us to discuss about the individual rather than the situation and creating unnecessary conflicts that, for sure, are not going to help us improve code or work environment quality.
Interested in joining one of our teams as we grow?
If you’d like to join us on the journey of designing the future of mobility have a look at some of the roles we’re looking for here.