How we scripted everyone to code review in the team
Getting all the team to code review can be a real challenge. Here is the story of how a simple random review assigning tool nudged everyone to code review.
This is an old story, I wrote about it a long time ago, but I thought it deserved an overhaul.
It happened a few years ago, as I joined a team as an experienced developer. The team was mostly junior except one developer. They were trying to write tests and to do code reviews. Unfortunately, juniors did not feel they had the right to review other team members code. As a result, the only senior dev was crawling under code review, and had become a kind of ‘clean code enforcer’.
It was not sustainable for him. He could not review all the code, and quality of reviews was suffering. As a consequence, the expected learning was not happening through reviews.
The project was ambitious, and we needed all the team to skill up.
Championing code reviews
I remember reading Karl Fogel’s, Producing Free Open Source Software at the time. He describes public reviews as:
- There should be at least one review for every commit
- Anyone can review anyone’s code
That looked like a way to encourage sharing and learning.
To walk my talk, I started to code review myself every day. I would dedicate around 1 hour to code reviews every afternoon before I left.
To make juniors code review code as well, I started to ask them for to pair-review my code. That made them uneasy at first, but they soon saw the value of code reviews.
This was working better, but we were spending a lot of energy in the process. Some code was also still not reviewed. We raised the point in retrospectives.
A simple script
The company was using an online code review tool called Code Collaborator. The process was ok, but still not great. One Friday afternoon, I wrote a quick script to randomly pick a reviewer for every new commit.
(As it uses outdated tools, the script itself does not have much value today. Ask me if you want it though).
I demoed the tool to the team. As we had raised the issue in retrospective and the team agreed to give it a try.
💡 Maybe there’s a simple script you could write to smooth out the code review process to make it catch on?
The result
The tool caught on almost immediately. All the team was reviewing code, and all the code was reviewed. As a consequence, more interaction, more learning and more continuous refactoring was happening. We were writing more quality code, we had less bugs, less rework and the pace got more sustainable!
Second order effect
The improvement mindset is at the core of code review. Good reviews should follow the motto: “That’s great, and how can we make this even better?”
The team applied this improvement mindset to code reviews themselves. That’s what people said in the next retro. “Reviews are great, but they are stealing time away from programming. Could we make this even better?”
I had been suggesting pair programming for a few retros already, and they decided to give it a try… and it sticked! (If you want to read the end of the story, it’s here.)
💡 Losing time in code reviews made the team switch to pair programming.
I couldn’t have expected that a simple script would nudge the team into pair programming. But that’s how complex systems behave, don’t they?
DIY
If you are in the situation where only a few people review code, give this a try. The script only took me about 2 hours to write. Tooling is different now, so it might be even shorter today.
Why not be even bolder though and skip a few steps? Start every day with mob-code-reviews as Carlos Matias suggests!
Leave a comment