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 you’re critiquing code, not the coder. Make sure your tone is not personal and that it’s 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 aren’t as knowledgeable or experienced as you. Use the opportunity to teach them.



  • Remember that everyone – even you – makes mistakes. You’re 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 don’t find as many errors and they don’t see you making the same mistake over and over.



  • To lessen a criticism’s 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 didn’t 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. Don’t 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.



Close

Add a little SmartBear to your life

Stay on top of your Software game with the latest developer tips, best practices and news, delivered straight to your inbox

By submitting this form, you agree to our
Terms of Use and Privacy Policy

Thanks for Subscribing

Keep an eye on your inbox for more great content.

Continue Reading