Adam Johnston

What percentage of development teams carry out code reviews? Do you have a number in mind? Because a few months ago I happened across a tweet by Mattias Petter Johansson and I was honestly a little surprised by the results of his poll.

At just a little over 50% requiring code reviews to be part of their team’s engineering process from a pool of nearly 1900 respondents, perhaps you can understand my surprise.

I am a big believer in code reviews, in particular; paired code reviews. I have found them to offer great benefits and in this article I want to outline three of those I think are the most important. With pros must come cons and there are, so I will touch upon them also.

The original tweet & poll from Mattias Petter Johansson

Why Do Code Reviews

To give a bit more context, I’ll start by outlining the process of code reviews that I am familiar with. Many of the developers are comfortable with working in isolation. We’ll discuss approaches to solving problems and provide help to one another when called on but we rarely pair program. However, we do code review in pairs. All developers are encouraged to be the code reviewer, regardless of their seniority.

Knowledge Share & Developer Growth

This is, I believe, one of the most important reasons to code review. One scenario might be that the reviewer’s skillset is more expansive than the developer’s which allows for the opportunity to offer improvements, guidance and insights. This is an excellent way to boost a skill you may not be as strong in, at least not yet. Or, perhaps, the developer in need of a review may be more senior and the reviewer junior or vice versa. This is a fantastic opportunity for one developer to pass on any pearls of wisdom to another. In fact it’s a win-win situation and a learning loop. The developer will have learnt of new techniques and can pass this knowledge on to others. Both developers get to learn, teach and grow.

Onboarding, Practices & Culture

Introducing new developers to your team, explaining workflows, processes and the way you’d like to work together can take time. Doing code reviews across the wider team will allow newcomers to meet other developers and also learn about the engineering teams practices without having to go through pages of documentation. It’s certainly more fun, and, as a consequence, they get the knowledge needed in a faster and more engaging way.

We work in distributed teams so jumping on a hangout and sharing a screen has the benefit for all of us to stay in regular contact and hopefully feel like just a single engineering team.

Quality Assurance

Code review is a great form of quality assurance, two heads are better than one and when you’ve been working on something for some time, you may have missed something. A bug that slips through that you’re sure you would have noticed. Having a fresh pair of eyes look through the code will help to catch that sneaky one.

A lot of the time just the practice of going over your code with other developers will shine a light on problem code. Does this make sense to you? Could this be improved? Are there alternatives that we should consider? These control questions can be asked to the reviewer. After a long day I’ve gone back to code and not been able to make sense of it myself and so here’s a chance to put that right. As I stated in the beginning of this article, the system is not perfect. Let’s look at the cons and discuss ways to deal with them.

Why Not to do Code Reviews

So with the good must come the bad. I’d be disingenuous if I didn’t cover them but with that said I don’t believe that any of the bad is enough of a reason to not code review.

Time

When you’re using your time to look over someone else’s code you’re not going to be working on your own. Of course in the grand scheme of things, if you’re pushing fewer bugs and you’re creating less tech debt you’re potentially saving time in the long run. However, in an agile environment with a bunch of tickets waiting to be done I can see how it might feel like it’s hard to spend that time. You can try and time box the code reviews. Smaller commits with good descriptions of the changes should help keep the code reviews short. Besides, completing small tasks one after another is a good feeling.

Only Human

While having someone else to look over your code can lead to finding bugs early and even improving it before it goes into production, it’s definitely not infallible. We’re only human and so mistakes can slip through. Code reviews won’t replace an acceptable test suite and even a second QA process that will check your product, but they’ll hopefully catch issues sooner.

To Sum Up

Using code reviews in my current position has given me the opportunity to learn and teach. I can share my knowledge to others when I review their code and I regularly learn something new when people review my code. Even if it’s not a perfect system, it has led to great, constructive debates and made my day-to-day job of coding more collaborative, engaging and fun.