What are Code Reviews?
A Code Review is essentially what it sounds like: a review of code before it is approved/accepted into the codebase. The general flow goes like this; an engineer writes some code in order to fix a bug/address some item of work. The engineer sends out a Code Review/Pull Request, basically asking for their changes to be accepted into the main body of project. One or more other engineers review the code changes, leaving comments/feedback, and either approves or rejects the changes. Rejection is often a temporary state asking for the comments/feedback to be addressed and the updated changes submitted again for approval.
The idea of this flow is to ensure that code entering the project meets a variety of expectations and standards, enforced by everyone on the team. The requirements being enforced often include coding style standards, unit/other testing, and general code quality. This process also provides an opportunity to spot check the code for any potential bugs, logic issues or other problems. It is common for this approval gate to require at least two other engineer’s approval before the code changes are allowed to move forward. But all parts of this process vary significantly team by team.
Code Reviews should not be the place where feature/implementation design feedback is discussed. This should happen long before code starts to be written.
Image for post
Photo by Kevin Ku on Unsplash
What Other Benefits Do They Offer?
As outlined above, Code Reviews provide a number of quality gate, process, and standardization benefits. But there are many more, often less appreciated, potential benefits to the team, the resulting code, and the project as a whole. These are just my top three.
Sharing project knowledge
Code Reviews are a great way to broadcast detailed knowledge about what changes are happening on a project. Having knowledge shared through the team versus locked up in silos (worst case in silos of one), has a very tangible impact on a project’s momentum and future. For those on the team actively participating in the Code Reviews, it acts as a ‘news beat’ or a pulse of the changes flowing into the codebase. This enables engineers to both stay up to date on how things work, but also allows them to plan their current and future work by taking these changes into account. For example, seeing an area of code is changing can help avoid conflicts if another engineer is about to make changes in the same area. Additionally, it may influence the implementation details of their next task if there is overlap.
On top of all of this, if your project involves an element of on-call rotation for handling live site issues/incidents, then Code Reviews provide a heads up for changes about to be deployed to Production. The on-call engineer can use the feed of incoming code changes to raise their awareness of what is changing. This helps speed up the identification of the source of issues if things start to fail in Production. When incidents occur, it is often due to changes somewhere in the pipeline.
Opportunities to teach
Having a gate blocking unreviewed code changes going in helps ensure the health and quality of the codebase. But keeping the quality of code high requires continuous learning and education across the whole team. Code Reviews provide a direct and explicit way for the senior members of the team to teach those that are more junior. The very intent of a Code Review is to seek feedback and make the necessary changes before the code is considered ready. This explicitness removes some of the awkward barriers around providing feedback. In the context of a Code Review, the feedback is not unwarranted or unprovoked criticism. It is sought after and discussed in a public venue. This transparency helps ensure that the feedback provided is constructive and allows the feedback itself to be reviewed and critiqued.
Encouraging this culture of asking for, providing, and accepting feedback as part of the standard process helps the team move forward in a unified way. Many senior engineers will eagerly take the opportunity to help drive the team’s standards, mentor those more junior to the codebase, and lead by example. And this is a great growth opportunity for them.
Opportunities to learn
Receiving constructive feedback directly on the code you are developing is a great way to keep you focused on code quality. But Code Reviews offer other, more fruitful, ways to learn too.
Code Reviews are a great opportunity for those new to a codebase to see how the more seasoned on the team work. By taking the time to peruse current and existing Code Reviews, an engineer can get insight into how the team operates and how specific engineers approach problems. It is a good way to get exposure to different coding styles, problem solving and design patterns, and the inner workings of a system. As well as to observe the etiquette of the team, both in how they give and receive feedback, as well as adherence to coding standards and other expectations. Ideally, the Code Reviews should also provide specific context on the code being observed and discussion/feedback around the choices made, versus trying to wade through an enormous codebase without a guide.
Given all these reasons I strongly encourage every engineer on my team to carve out time to participate in Code Reviews. Whether they are seniors helping raise the standards and educate others, juniors looking to expand their experience and exposure to other’s code, or anyone wanting to keep relevant on the changes flowing into a project. There is a lot of information to be gained by being a part of those discussions.

#leadership #productivity #programming #software-engineering #code-review