StephOne of the most powerful ways to improve or maintain code quality is proper code reviews.
But many teams face challenges from outside of Engineering to protect the time to do code reviews well.
Here’s how we would explain to a non-technical colleague why code reviews are essential.
First, you will lose engineers without a culture of mentorship and learning.
Engineers are among the most in-demand positions for all companies across the globe. COVID and Work From Home sped up the globalization of the talent market for engineers. As a result, companies need to invest in their Engineers aggressively. If you’re not actively building a great place to work, you’re on the losing end of the war for talent.
One of the ways to build a great place for engineers to work is to shape an environment that supports mentorship. Learning and exploring on the job is no longer a “perk” but a requirement. Engineers are deeply curious, and code reviews are a great way to facilitate a learning culture.
Second, you will fast-track the effectiveness and productivity of new engineers.
If you hire new engineers or bring in third-party development shops and freelancers, you want to ramp them up as quickly as possible. Code reviews fast-track the onboarding process.
The difference between an effective and ineffective onboarding is six months or more of lost productivity. Unproductive onboarding means wasted financial resources and time, slower time to market, and ultimately, losing pace with your competitors.
Third, engineering effectiveness and velocity will be lower without code reviews.
Your CEO will undoubtedly have heard the concept of “10X developers,” rare developers who are significantly more productive than everyone else. Whether or not that’s true, the idea of the 10X developer is informed by a substantial uplift in skillset – and so they are better able to contribute to the code and the team.
Think of code reviews as a means to 10X not one developer but many. It’s a great way – in our view, perhaps the best way – to continuously improve the quality of the entire team, not just an individual. This is because coding is fundamentally a craft, not a competition– a rigorous skilled activity that requires learning from more experienced experts and one that requires deep knowledge and concentration. The greater the investment in growth and learning, the higher their effectiveness will be.
Gartner says the productivity difference between low and high-performing engineering teams is 53%. To us, that estimate merely scratches the surface.
How can the rest of the organization's non-tech employees, such as Product and Sales, assist in making code reviews more effective?
- Trust the process
It can feel so urgent that a feature be added right now, or a piece of code pushed to production by the close of business. We get that.
But skipping the step of a code review almost always makes things worse later – and sometimes, not all that much later.
Trust us: no user is happier with a buggy version of the code than with a more complete version in the next release.
- Protect review time
The most essential thing that the rest of the organization can do is understand that code reviews are part of coding and time should be set aside in sprint planning and other kinds of work estimation.
As discussed above, code review “return on investment” is extremely high, and so organizations need to protect that time.
Organizations who estimate and plan engineering activities should include a buffer of 10% to 50% for code reviews beyond code writing, depending on the complexity of the code being written, the coder’s skill level, and the reviewer’s skill level.
- Cement its importance
The point above about formal recognition and or “consequence management,” is as true for the rest of the organization as it is for the Engineering team.
If the CEO celebrates feature completion, does the CEO also celebrate code quality, developer mentorship, and code reviews? Does the annual performance process reflect reviews too?
Remember, an ounce of prevention is worth a pound of cure. Investing sooner in code reviews through celebration and recognition means avoiding more expensive outcomes later like technical debt and developer attrition.
