Tips for Developers: Social Effects of Code Review, Part 3
In part 2 of this series, I listed some tips for managers who are trying to get a team to add peer code review to their software development process. Most of those tips were about setting the stage for successful reviews by outlining the right "tone" and defining expectations.
Tone is also important for developers who are doing peer code reviews. Specifically: the tone you use in your comments about a peer's code can make all the difference in the world. In other words, it's not just what you say that matters, but also how you say it. Equally important is that when your code is being reviewed, you are able to accept comments from other reviewers without getting defensive. Some tips for accomplishing both:
- Remember that youre critiquing code, not the coder. Make sure your tone is not personal and that its clear your intent is to improve the code, not take shots at its author.
- Be respectful to and patient with everyone, especially team members who arent as knowledgeable or experienced as you. Use the opportunity to teach them.
- Remember that everyone even you makes mistakes. Youre human like the rest of us, and we all mess up sometimes.
- Take advantage of the opportunity to learn from others. No matter how much you know, you can always learn new tricks and techniques from your teammates.
- Review your own code and create a checklist of the problems you frequently make. Before you send your code for review, check your own code for the errors on the list. This way, your colleagues dont find as many errors and they dont see you making the same mistake over and over.
- To lessen a criticisms sting, ask a question instead of making a statement. Asking for the author to explain their reasoning behind something acknowledges that you respect them. What was your thinking in using this function call instead of that one? is much less confrontational than This is the wrong function call. Use the other one.
- Avoid asking accusatory Why questions. Instead of saying, Why didnt you
, ask something like, What did you have in mind when you
? The tone of the ensuing conversation is now entirely different.
- When disputes arise, win and lose gracefully. Dont rub in your victories nor sulk and pout if you were wrong
It's all in how you approach it - with the right tone, code review can have a positive effect on you and the other members of your team, and of course, on the quality of your code.
This is the final entry in a three-part series. The tips from all three entries are available in this recently published white paper: Improve Quality and Morale: Tips for Managing the Social Effects of Code Review.