What should you know about a human side of code review?

No comments

Imagine yourself sitting in front of a compiler, tasked with fixing a small bug. But you know that as soon as you say “I’m finished,” another developer – or worse, your boss – will be examining your work. How do you feel? Anxious or encouraged?

As software engineers, we take pride in our work (as well we should, it’s quite an effort!) but this pride can make us anxious to have our code reviewed. (The good thing is, that it gets easier in time.) Code review is the moment when the introvert inside our mind wants to come out. It doesn’t matter if you are introvert or extrovert or how experinced you are, you can feel hesitant to show others your code (especially if you are a junior or a junior in code reviews)

Reviews present opportunities for both the author and the reviewer to expand their capabilities. You can learn from each other’s mistakes, ideas, experiences. But if you are afraid of the code review process, the positive results disappear. On the other hand, the proper code review can encourage you to take part in a next one.

So how to make this process less painful to both developer and the reviewer?

Treat the review as an opportunity to improve the system, not to pinpoint the developer errors.

Half of the code review success is the matter or attitude. To see mistakes as a bad thing is easy but we are all prone to them so you need to remember that the point of software code review is to eliminate as many defects as possible, regardless of who “caused” the error. Remember, that finding defects means that the author and reviewer have successfully worked as a team to improve the product.

Treat the review as a learning opportunity

As I’ve mentioned already, the code review is an opportunity to learn for both the reviewer and the author. It’s an opportunity to correct bad habits or learn new tricks. It helps you to be a better developer, to continuously enhance your skills and encourages best practices.

Remember that there is often more than one way to approach a solution.

Respect each other’s approach. Both sides might have a different idea on how to code something, but different isn’t necessarily wrong. The goal is quality, maintainable code. If those goals are met and the coding standards are folowed, that’s all to ask for.

Explain your point.

A code reviewer many not know the exact context and challenges, when the code was written. The author may not take into account some functionality the reviewed code influences (that often happens especially when working on monoliths or legacy code).

Be nice and respect each other

Reviewer: Be kind to the coder, not to the code.

As a reviewer, make all of your comments positive and oriented to improving the code much as possible. Treat people who know less than you with respect and patience.

Author: Seek and accept input from others, especially when you think it’s not needed.

You can learn from a junior as you can learn from a more experienced developer. You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don’t take it personally when one is uncovered.

Ask questions in proper way rather than make statements.

A statement gives a vibe of an attack.

Instead of “You didn’t include this and that here” you may ask “What was your reason to write this and that in that way?”

Similarly, when forming a question try to avoid “Why”. Which one sounds better:
“Why didn’t include this and that here?” or mentioned before “What was your reason to write this and that in that way?”
“Why should I write this and that?” or “What to you think is the best way to write this and that?”

Teach, explain and show, never force.

Never force software developers to change the code written by them. It may hurt their ego and they may repeat the same mistake if they do not understand the reason behind code change recommendation. Highlight the issues in the existing code and its consequences. Explain relevant principles such as S. O. L. I. D or cyclomatic complexity.

Fostering a positive attitude toward code review and defects found can do more for true team building than many other techniques. As software developers, we love to talk about the code, the techniques, the solutions, ideas, frameworks. We love to learn. So well done code review is seen as a mean for learning, growing, and communication and can really do miracles.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s