Reviewing Code Reviews

Reviewing your team's code review is an often under-leveraged tool you can reach for as an engineering manager in order to improve the efficacy of your teams' code reviews. (That and instituting a code review playbook, but I'm assuming you've done that.)  

Don't worry though. If you're an individual contributor there are still some takeaways for you here.

Why bother?

Like most things we do as software engineers, you were probably given somewhere between little and no training on how to do a good code review. At best you were at some point in an organization that modeled effective code review.

So in the spirit of being the change you want to see in the world, let's dive in and see how we can make this better.

So how do we do this?

Right now your team may know that code reviews result in better outcomes. But they aren't sure about how to actually do them well. First you should establish a code review process, but folks may still struggle at that point. So, what's next?

That's where you can step in and conduct a review of their review, either sync or async.

Async you can conduct your own code review using your process as if their review wasn't in place, and compare the two. Look at what they missed compared to what you noted, and use that as an instructional piece during your next 1:1 or other coaching session.

You can also use this method as an individual contributor without the help of your manager if your team requires multiple code reviews. Look at what others on the team pointed out when they reviewed after you, and ask yourself why they pointed out the issue and you didn't?

The other option, sync, is to go through the code review in a pairing style, where you act as a fly on the wall, while the reviewer discusses what they're thinking aloud. This allows you to give immediate feedback on the process, how they're working and how to improve.

In either case you also have the benefit of hindsight. If someone approves a piece of code and it results in issues in production you can then use it to get an idea of how to improve the code review process as well. Each defect represents a potential learning opportunity.

Objections

We don't have a process?

Oh, you do. You just haven't written it down, but it's your default. It's what you do each time you get a request for a code review. It might be very thorough, or it might be "LGTM". Likely it's somewhere in-between. In order to better coach yourself or your team on the process, you would be well served by writing it down.

My manager won't review my reviews?

That happens. Managers often have a lot on there plate. The good news is you can have other folks handle the review as well and compare the two to see where yours is lacking comparatively, or where yours is comparatively better, as mentioned earlier.

If you've got thoughts on how else to improve code reviews I'd love to hear about them via email or Twitter.