If you would ask 100 developers if code reviews were a good thing, probably 99 of them would say it is. And for the most part, I agree. However doing code reviews is a broad concept, and probably every company or opensource project does it differently. In this blog post, we will take a look at how a poorly implemented code review process can be the source of distrust!
I was lucky enough to see the Science of code reviews by Rick Kuipers talk in action at PHPBenelux a few years ago. If you want to catch up on what code reviews were again, and some tips and tricks. I definitely recommend checking out the talk.
The origin of Code reviews
The code review process most companies used is inspired by the open-source community. Where everyone is allowed to contribute to a project. This does mean there need to be some strict requirements and guidelines to make sure a contributor does not mess up the project. The mindset of these cases is, make our code review process strict and watertight. With less chance to end up with bugs and outages.
The tech world adapted this code review process and made sure their internal devs teams follow it as well. Sure this was an improvement from when we manually uploaded through FTP and no one looked at our code. But it also slowed us down. As a Scrum master, I am always looking at ways to make the team can deliver as much value as possible. Not by working harder per se, but by working smarter.
Personal experiences
About two years ago, when my junior developer days were long over, we had a session to brainstorm on things that could help us go even faster. A heated debate was started on the fact if we should stop doing code reviews. The result of that meeting was to make some of the requirements of code reviews less strict.
First, let’s take a look at how our code review process was. The time that most pops into my mind were when I was one of the less experienced developers in a team with some great developers. I can remember feeling excited when I transferred to that team. It felt like a great learning opportunity. The code review process was as follows:
- At least 3 other teammates need to approve my work
- When my code was approved, only a few senior developers could merge the code
- After the code was merged, only a few could actually deploy my code after testing
Codebases feeling more and more difficult to get into
The process above was heavily inspired by the open-source community. But there was one big difference, I was not just any random developer looking to contribute to a project in my spare time. I worked at the company as a developer for 3 years. I was a member of the team, which I spoke daily, pair programmed with, and refined the tickets with.
At the moment I did not really realize it, but if I look back on the time spent in that team, it was mostly radiating with an absence of trust. All the steps are designed to keep developers from making small mistakes. But at what costs?
The code review process took quite a bit of my time. Not just to get 3 developers to review it, but also to fix any comments. It actually took quite some time before I was deemed “good” enough by having a pull request without any comments on it.
The question you can ask yourself is: “Is it worth slowing down developers to prevent them from making a mistake”. I did agree with that sentence at the start of my career, but with the more experience I get, I am moving to the other side. Controlled mistakes are what fuels learning and ownership.
Improvements
How can we turn around code reviews to make them a source of trust? Glad you asked! The following changes are what I changed in my teams:
- One person approving the code should be enough
- Pair program more.
- Have automated code style/sniffers analyzing the code.
- Let everyone merge & deploy their own code, once the criteria above are met.
The changes above should help to facilitate collaboration. The reason behind it is that big decisions should not be discussed at the review stage. At this stage, you are too late. A senior developer does not agree with the direction the ticket is developed? You should have paired, refined, or collaborated in any other way. But most importantly, the changes above give the signal that we can trust the developers.
Conclusion
Do not do code reviews to make sure your developers do not create bugs or make mistakes. Empower them to collaborate early in the process to make a lot of the steps in code reviews redundant.
Check my latest post: The most important skill for a developer to master. Or sign up for the newsletter.
Top comments (0)