Facebook recently changed their mantra from
Move fast and break things.
Move fast with stable infrastructure.
Mark Zuckerberg went on to say ““We were willing to tolerate a few bugs to move fast. But having to slow down and fix things was slowing us down”. Working quickly while engineering things the right way is a balance all teams have to find, especially for startups where speed is necessary for survival.
The code review is one activity that, when done correctly, can help your team achieve both objectives – shipping code quickly and stable systems.
The problem is that code reviews are very easy to get wrong, mostly because they are cultural and driven by human biases. Usually one or more of these things happen:
- The engineering team pays lip service to code reviews, doesn’t prioritize them, and simply doesn’t find the time.
- A bug finds its way into production causing bad behavior or worse. Management gets involved and code reviews come up as a solution. Engineers reluctantly agree but no framework is discussed for when and how code reviews should be implemented and who should be involved.
- The engineering team gets around to doing a code review. The entire team piles into a conference room, because hey it would benefit everyone, and one lucky engineer walks everyone through his code, standing on trial for every line of code, justifying a variety of details including coding conventions.
- The code review process is so painful, other engineers rather not bring it up again, and engineering leaders likewise don’t want to put their team through the ringer. Often the time-suck reasoning will be brought up again.
- Code reviews are implemented as a variant of pair-programming, which is less intense but still faces scheduling issues. Code reviews continue to fall through the cracks.
In the name of moving quickly, code reviews are often painful or swept under the rug. It doesn’t have to be this way and it shouldn’t.
Code reviews are one of the fews way to actually have confidence in your team’s production code and avoid having to revisit deployed code or re-design a certain component. This approach is a good example of “slowing down to go fast”.
While every team is unique, here is a framework for thinking about the code review process.
- Be Respectful. Leaders must foster a culture of respectful, positive feedback. Finding bugs at this stage is a good thing and a learning experience for everyone involved.
- Be Automated. Use a tool to automate as much as you can around code reviews. Here is a list of popular code review tools. Discuss with your team the tradeoffs and pick one. It matters most that your team uses it.
- Be Low Overhead. Code reviews should be asynchronous. Don’t hold meetings.
- Be Consistent. Make code reviews habitual. The code review is part of the deployment process.
- Be Reliable. Any piece of code that goes into production should be code reviewed.
- Be Timely. Follow-up during stand ups. If you’re being blocked by a pending code review bring it up right away.
- Be Thorough. Take the time to understand the code you are reviewing. Make sure that once code review is given, the feedback is incorporated. Require a follow-up code review if necessary, until the “ship it” thumbs up is granted.
Code reviews are by no means a magic bullet for perfect code. However, done correctly they can improve your team’s velocity while simultaneously improving the quality of your team’s production code base. As an added bonus, code reviews can expedite the knowledge sharing process across the team. This has the advantage of enabling more people to contribute to more pieces of the code base over time, allowing your organization to move faster.