As a technical lead, senior engineer, or technology director, code review can be one of the most valuable and force-multiplying tasks during your day.
Code review is often thought of by new managers or leaders as simply about identifying bugs, but I think it’s more than that. Especially when you’re working with junior developers, code review is an educational tool. It’s a chance to help your team learn best practises and write code that remains stable and reliable for years to come.
In my code reviews, I aim to:
- Identify bugs. As noted before, this is the most common thing people think about during code review, and of course it’s true: it’s an opportunity to identify mistakes or bugs before they make it into the code. As a technical lead, you might not have time to personally QA every pull request, but you can at least spot typos, mistakes, and obvious errors.
- Reduce fragility. As you gain more experience and move into senior and leadership roles, that should also come with a better understanding of where code is most fragile. Fragile code isn’t easy to identify for less experienced developers, but will likely jump out at you. Maybe it’s a particularly complex regex, a function with multiple return types, or an interaction with a finicky third-party API; you probably have a sense of where things might fall apart, and this is your chance to prevent that.
- Increase clarity. Clear, well-documented, easy-to-read code isn’t just a matter of preference: it’s an insurance policy against future change. However that manifests for you (I like to encourage inline comments, sufficient white-space, and clearly named methods and variables), it’s important to set the standard and
- Reduce complexity. This goes hand-in-hand with reducing fragility, but takes it slightly further. Junior developers can fall into the easy trap of writing code that’s too complex. That might mean a few too many conditionals in a method, or choosing a solution that is clever, but perhaps a little too intricate. Not all fragile code is complex, but all complex code is fragile. Be mindful of where you introduce complexity, and limit it where you can.
- Enforce consistency. As a lead engineer, you are one of the few people with a comprehensive, 360º view of your codebase. As such, it’s implicitly your job to make sure the code that enters the codebase is consistent. You can get some help with this from automated linting tools and good documentation, but code review also gives you the opportunity to add context, so you can explain whyyou enforce those requirements.
With these outcomes in mind, your code reviews will not only be a defensive tactic centred around avoiding mistakes and bugs, but they will also help you stay on the offensive by actively building reliability, predictability, and consistency into your code.
Great code review ensures you avoid the bugs of today while preventing the bugs of the future.