In part 1 of this series, I described the importance of getting up-front buy-in for adding code review to a team's existing process. The task of getting a team to embrace code review frequently ends up in the lap of the development manager, and if you're a manager, your most difficult job is probably dealing with your team's emotions and human interactions.
Those emotions and interactions are important because one of the most overlooked factors when doing code reviews is a positive outlook. When properly implemented, code reviews can be fun, light-hearted, and build team morale. But when your team is put on the defensive, you run the risk of developing bitter feelings amongst both the authors of the code and the reviewers.
To create an environment where positive emotions and interactions come from doing code reviews, the key to success is to set the correct tone. These tips can help you get started on the right foot:
- Explain to the team that you want them to find defects. The more
the better. Each defect they find is another one that doesnt clog up
the QA pipeline, or worse, get into the customers hands.
- Make sure everyone (including yourself!) understands that code review is all about reviewing the code. The goal is to review the code, not the person who wrote the code.
- Encourage team members to review different peoples code. That way, everyone can get to know others and their styles.
- Never use metrics from code review as part of your teams performance evaluations. Make it clear to the team that review statistics such as number of code defects will never be used in reviews of the person who wrote the code or the person who reviewed the code.
- Don't single people out. If someone is not approaching code review with the right attitude (e.g. bullying their coworkers or doing political jockeying), dont single him or her out. Have a general discussion with the group instead.
- Insist that your team always review at least some code, and explain why. When developers know that their peers will be reviewing their code, they instantly become better developers. They dont want their colleagues finding bone-headed mistakes, so they give their code a quick review themselves before checking it in. They even pay closer attention as they work so you get better code before reviews even happen.
It's all in how you look at it - with the right approach, code review has extremely positive effects on teams and their personal interactions.
This is the second entry in a three-part series. In part three I will
provide some tips for developers. If you do not want to wait,
however, check out this recently published white paper: Improve Quality and Morale: Tips for Managing the Social Effects of Code Review.