Code review: What 8 years has taught me - Part 1 of 2

As developers we all know that reviewing code is a beneficial and necessary process. Remember: Code review can help make your entire team more efficient, your software more maintainable (and maintenance is 70% of the cost of software), and your job more rewarding! At least in theory! In practice, nobody really wants to review code—a task perceived as tedious and time consuming.

Everyone here on the Tuleap team shares a strong belief that code review is an investment that pays off in more than one way. But we didn’t just wake up one morning believers! We have been reviewing code for more than 8 years. Our code review process has gone through multiple iterations, and with each iteration we have made improvements.
To give you an idea of what code review looks like for Tuleap software, in 2018, our 20 developers and reviewers submitted 38 commits per work day (for a total of 8,581 for the year). The median review time between a push and a review is 1 hour, the average time, 16 hours.

This article and a follow-up article soon to come will show you some of the things we’ve learned in eight years reviewing code. As Enalean’s CTO and Tuleap product owner, I have seen the process from all angles. Don’t miss this chance to benefit from eight years of experience in the time it takes you to read two short blog posts. You’ll learn why everyone has to get involved, why talking to each other matters, and why there’s no worse time to skip code review than in an emergency!

If you would like to talk on how you can get the most out of code review, ping me on Twitter or on Linkedin.

There’s no such thing as too many cooks

In other words, everyone on the team, regardless of where they are in the org chart, has to be capable of reviewing. And there’s no better way to learn to review code than to…review code!
The first person to review any code should be the developer that pushed the code. Step back and take a critical look at your own code. A pre-commit code review is essential to catching those inevitable mistakes and is the precursor to empathy and open communication between peer reviewers.

Experienced developers can benefit from reviews by junior developers—and even interns. This is the magic of the beginner’s mind…take advantage of it! Junior developers, on the other hand, can learn a lot from reviewing more senior peers’ code. Yes, an intern refusing a senior developer’s commit can be a traumatic event. But sometimes you have to take one for the team. Ego has no place in the code review process. It takes time to build up your code-reading muscles. Think of code review as a vital part of your training routine. With each workout your team will become more efficient…and your releases will be more robust and maintainable.

This is what a developer told me about code reviewing:

I spent an entire month doing nothing but reading code—something I never imagined doing. It was tough going, but I really felt that I had improved as a developer and that I had made a concrete contribution to getting the release over the finish line.

The integrator gets the final word and is authorized to integrate the reviewed code.

Sometimes you need to turn off the tools and talk

Code is more art than science. Some parts of the code review process can be automated (Git Pull Request and Gerrit are two of the tools you can use), but you do get to a point where human intervention is a must. In fact, code review is a great way for development teams to learn (or re-learn) to talk to each other.

A good code review process will facilitate communication and leave detailed records. And the benefits are double: the more specific and detailed your code annotations and commit messages are, the easier it is for your reviewers to understand your rationale and for the team to retrace the breadcrumb trail to a bug or regression in the event of an issue later on.

Effective communication means giving each other the benefit of the doubt (the developer who pushed the code did his or her best) and providing specific and constructive feedback.

But there’s one caveat: If your team is already dysfunctional, the code review process will only amplify what is broken. Fix your team dynamics first, and then bring code review into the mix!

Emergency? Don’t skip the review!

Resist the temptation not to review code in the event of a “code emergency”! Emergencies require particular attention—and only a thorough and thoughtful human code review will do. In fact, you should have a specific code review process in place for urgent and/or critical issues. Plus, as your team gets better at reading code, reviewing code, and communicating effectively about code, “emergencies” will occur less frequently and, when they do, you will be able to resolve them calmly and efficiently, retracing your commit annotations and messages until you find that bug or regression!

Start fast (like now!) and make adjustments often

If you are ready to introduce your team to code review, the first step is to get started! Seriously, choose your tools (Slack, email, Gerrit, etc.), set up a simple process, and go! Then make adjustments often.


  • Get everyone involved
  • Talk to each other
  • Resist the temptation to skip CR in an emergency
  • Start fast and adjust often

If you still need convincing, come back for my next post for some of the nuts and bolts of the code review process!


As CTO of Enalean and Tuleap product owner within Enalean, Manuel’s mission is to keep Enalean’s tech team happy. This means providing our developers and other tech staffers with a challenging and rewarding work environment guided by a single philosophy: to be accountable to our customers in everything we do. Manuel spends much of his workday…you guessed it…reviewing code! He also dabbles in systems administration, continuous integration, and other software-engineering tasks.

Other resources to go ahead

Share this post

Leave a comment

To prevent automated submissions please leave this field empty.

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Websites located at and other subdomains need to store and access cookies on your device. We need your acceptance. Get more information. Yes, I agree No, I disagree