Code review like a boss

In my 15+ years of software management, I have found no software development practice that improves quality, builds skills, or reveals the best developers like the code review.  The code review or in git parlance, the pull request, is the number one way to set the tone, rhythm, and bar needed to build a high performing team.  We all know bugs are cheaper to address the sooner they’re found and automated tests can find bugs and regressions.  However, automation can’t tell you the code isn’t following best practices, looks like a big mess of spaghetti, or is going to result in a maintenance nightmare.  Since the code review is such an important practice, it’s worthwhile to find the most effective way to review code to maximize its benefits.  Here’s how to code review like a boss.

Be the Enforcer

The first step is to meet as a team to list the principles that should be enforced in the code review.  Core on that list are things like architecture rules, security, privacy, maintainability, error handling, deployment/setup work, documentation, best practices and patterns.  Code review principles are worthless if not enforced.  Encourage the team during code reviews to be hard core and strict about enforcing the principles, regardless of whose code they’re reviewing.  Code authors need to have thick skin and not expect code to get merged in or accepted on the first review.  My team was once referred to as the code review equivalent of that famous Seinfeld character that would say “No soup for you!” because they felt like it was “No merge for you!” every time they submitted a git pull request.  We took that as a complement.   I have found the best developers welcome the discipline and the entire team picks up their game when they know up front that their code will be reviewed thoroughly.

“Code review principles are worthless if not enforced.”

Keep it Interactive

No one said reviewing code had to be a boring read-only exercise.  Get the code on your machine, build it, run it, and poke at it.  If you’re doing the code review in person, the person reviewing the code should be the one at the keyboard navigating while the author of the code explains it all.  The more engaged the code reviewer, the better the code review.

Keep it Small and Frequent

Code reviews should be small and frequent.  Reviews that are 300 lines or less work best.  I have years of anecdotal evidence that this results in higher quality code that is also backed by numerous quantitative studies (like this one) that show that high churn changes result in higher defect density.  If there is a long running feature being done in a separate code branch for an extended period of time, then have small and frequent code reviews in that branch rather than having one big bang code review later. (The “bang” in big bang code reviews is your app crashing at some point in the near future.)

Pair Up Wisely

Code reviews are an excellent opportunity for the more experienced developers to teach developers that are new to the code base, language, or technology.  Therefore, make sure the right people are reviewing the code.  Of course, everyone needs to learn how to review code.  In this case, you can have multiple people review the code—just make sure an experienced eye is involved.

What’s Missing?

The top code reviewers not only notice what’s wrong with the code they are reviewing, they also notice what’s missing.  Is all of the deployment code there?  Internal and external documentation updates?  Did that new environment variable needed to run the test get documented in the README.md?  This is an acquired yet invaluable skill that only belongs to the best code reviewers.

Review the Code Review

Code review tools that preserve the code review comments and dialog are a valuable learning resource for everybody.  New developers can learn new patterns and techniques.  Managers can see who the leaders and keepers of code quality are on the team.  When there is a retrospective on a service outage or bug, you should look at the check-in or commit that caused the problem as well as the code review comments.  Everyone involved in this code should ask how this issue was missed and how the team can prevent it from happening again.

Conclusion

Make the code review a valuable part of your development discipline and code review like a boss.  When you learn to love the code review, you will build software and services that you and your customers love.

To stay up to date on blogs like this one, sign up for email notifications in the right side bar!