While working with developers you might hear that they have no time for code reviews. This should never be the case when working with responsible ones. Responsible programmers crave for code reviews because they understand the consequence of working on code that is not tested by others. If you are still not doing code reviews consider yourself being shot in the foot and continue reading 😉

I know what you think about code reviews:

they are not really important

they slow the development process

you don’t really have time (for these hipster developer ideas!)

Yes, it is an additional step that has to be taken in order to release and the whole internet is telling you: just ship it! But if you would have to choose one type of testing your code you should definitely decide on code reviews.

In the book Code Complete Steve McConnell has written:

“Software testing alone has limited effectiveness — the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent.”



He has also provided numerous case studies. His book in the second edition was published in 2004. Yes, more than 10 years ago. This is really not a new thing and you reaaaally should have already done your homework on this topic!

Ok, so I have convinced you that this is the thing. But you have your hands full of work and you can’t tell your client to wait multiple days because you need the code review to be done. Okay, but it’s not something to be postponed for days.

Yes, we do code reviews on a daily basis

Yes, we deliver!

The great secret of efficient code reviews lies in doing them constantly. We all need to maintain focus on development of new features and we hate distractions. A good way to keep sane while doing everything properly is switching to code reviews every few hours. I like to keep a habit of three code review sessions daily. I check what has to be reviewed once I get to work, just after lunch, and before going home. Once you get things rolling you will also notice it’s not taking a lot of time. You don’t rewrite half of your product every day*, right?

There are other aspects of peer reviews. They help lowering the project’s bus factor. You get to learn new things by reading the code and by being corrected by other people. You know your code will be checked by someone else so you don’t even try to use shortcuts. You have to remember about comments and proper formatting. Others have to understand your work. The responsibility for a functionality is split between more than one person.

I could talk for hours about the additional benefits of doing code reviews but I can only say that we believe in them so much we have developed an internal peer review process of our blog posts so we are delivering high quality text and we love it!

* Pro tip: once you do rewrite half of your app, you can set up a pair code review with another developer.