Code Review Process: 3 tips to deliver a better experience for remote-first teams

Code review sessions can be enjoyable or nerve racking, depending on how they are carried out. Some teams do it because it’s company policy, or just because it is an automatic part of their process.

The benefits of code reviews, although plenty, can only be reaped if the process is implemented correctly and for the right reasons. When someone spot checks your work for errors:

1. they get to learn from your solution
2. the collaboration helps to improve the organization’s overall approach to tooling and automation
3. it increases everyone’s overall understanding of the codebase, in particular those who are responsible for it and of the technologies we use
4. and it can contribute greatly in making everyone a better engineer

Code reviews aren’t just about getting a rubber stamp of approval from someone (often written LGTM, or Looks Good To Me). Every code review is an opportunity to ask questions, share knowledge and consider alternative ways of doing things. Done properly, both authors and reviewers can expect to learn and grow from this process.

Despite the fact that nobody imagined the upheavals of 2020 due to COVID-19 pandemic, we found ourselves having to adapt to a remote-first culture rapidly. Code review sessions too had required some reshuffling to produce anticipated results. Below are 3 ways by which we can create a better experience during code reviews:

1. Create your very own guide

Even though there are already numerous excellent online resources available, making your own charter allows for the creation of a shared, living document that would evolve over time as we learn more about what works and does not work for our teams.

While existing resources offer many useful global principles, a lot of the questions we had required local answers, specific to the structure of our organisation, our codebases and the design of our automated tooling and Continuous Delivery processes. An anonymous collaborative document can help source ideas, frank observations and anecdotes about code reviews from engineers of all levels of experience. Then, with feedback and advice from a range of viewpoints we can gradually distill those pieces of advice and experiences into a guide.

Furthermore, onboarding process for new engineers can also be accelerated, and the latter get to acclimatise to the work culture of the company in a more efficient manner.

2. Quality communication is Key

Often we realise that the real benefits of code reviews are communication and understanding. Making Zoom, Skype, Google Hangouts or Slack calls to talk it through can be friendlier and more efficient than back-and-forth debates on Pull Requests on GitHub. This is particularly important for growing, distributed teams where there is greater scope for confusion and misunderstandings. We also find group (a.k.a swarm) code reviews effective.

3. Remember to be kind

Emotions can run high during code reviews for both reviewer and reviewee. When pride is added to the mix, the situation can become explosive if left unchecked. Code reviews should always become an opportunity to try to understand the other person’s perspective, especially when new team members are contributing to an established codebase.

Language is also important – fighting over definitions and jargon can undermine the spirit of collaboration that ought to underpin code review. Commenting should be measured and to the point.