A scrum master told me the other day that the team didn’t want to do code reviews because it was boring and a waste of time.


I have worked with many teams during my time in software development. Some have been dedicated to a project and some have been on the steady improvement of a product.

The teams that perform the best are always the ones that care about quality. Not only do they create good value for their users. They have also come to realize that it is more fun to work when not having to tend to an ever-growing mountain of technical debt.

They have experienced the impact of code reviews.

In this article we’ll cover the why of code reviews and you get some tips and tricks on how to get your team started.

What is a code review?

Let´s start with Wikipedia’s definition:

Code review (sometimes referred to as peer review) is a software quality assurance activity in which one or several humans check a program mainly by viewing and reading parts of its source code, and they do so after implementation or as an interruption of implementation. At least one of the humans must not be the code’s author. The humans performing the checking, excluding the author, are called “reviewers”.


Why your team should do code reviews

Code reviews are a practice where we look at the code that we have written and then try to improve on it. The main reasons for this can be many things, but I have narrowed it down to these two things that I believe are the most important. Finding & fixing bugs and Sharing knowledge. I will also give some pointer on what to think about when trying out code reviews in your team.

Finding and fixing bugs
This is the first thing that comes to mind when somebody says code review. The idea is simply that more eyes and minds on the code is better than less. You get an increased chance of finding the small errors in logic, like a “greater than” instead of an “greater than or equal to” misstep.

Sharing knowledge

This is the more elusive part of why code reviews are great. By talking about and discussing the code you’ve just written, then the rest of the team will know more about what you have done and why you did it. This leads to time off. Yeah seriously, it does.

Think of a piece of code that you have written that is complex and hard to understand. Probably it is a core function of the product. Since it is core, then it means that all the fixes that is needed in this code is up to you and you alone. Because you are the only one who knows about it.

If you had done better reviews on this code, more people would understand it and be able to fix it. This means you need to spend less time on fixing stuff and get more time for developing new and awesome features. Code reviews are an investment in time.

How to start doing code reviews in your team (bigger headline)
There are three questions that have to be answered before doing a review. When to do it? What to review, and how to review it?


I like to timebox reviews. It is not fun to review huge chunks of code in a single sitting. I find it easier to do around thirty minute sessions. This also gives you an idea on how much code you should review in one session. The other thing I like is the author to be prepared, to explain what they have done, and walkthrough the code with the reviewers.


When deciding what you should include in your reviews, do a checklist with your team. The author then has an excellent tool for preparing the review. A pro-tip is to go with less is more. I once worked with a team that I coached into doing code reviews. Two developers got excited and decided to make a checklist. The checklist was about the size of a book. On the next retrospective, I asked them how they were getting along with the reviews. They said that they had not done any because the checklist was too huge to use. My only pet peeve on the checklist is that it should include reviewing the tests. Because that is another great way to clear out technical debts, unit tests. That is a different story.


The best way to get reviews going is to decide it is for improvements. Most developers want to improve, their skills and the product. I feel that this is a great way of framing reviews, to have them be about improvement and understanding, not about examination. I usually talk about getting improvements as result of change. Therefore, in order to get improvements then we have to be willing to change, and since change is unpredictable and we do not always know what change is the best then we must be willing to make mistakes. Code reviews are about opening up to fixing those mistakes so that our product improves.

Wrapping up

The best way it to follow the old plan-do-check-act cycle. Try it out in a sprint, do a retrospective on what worked and how it felt, take appropriate action and try again. Usually it sticks within a few sprints.

Do you want more tips and tricks, checklists and other stuff on embedded systems? Subscribe to our insights!

Happy reviewing