📋 Original Twitter Thread

Prior to joining Meta last year, I only had the experience of working in startups. It was a huge change for me coming from a startup background to a tech giant. Though it was challenging in the start I must say it was a year full of growth.

Naturally, I couldn't help but notice that bigger companies have a better code review system in place unlike most of the startups. Here are my few takeaways that may help your team in improving your code review process

In an early-stage tech company, every time there is a discussion around setting up processes, about reducing tech debt or reducing bugs in production and when the list is made to improve things, the first thing on that list would most probably be "Better Code Reviews".

All the engineers on the team agree to it, promise to raise a PR before merging code and undertake to do better code reviews.

Everybody starts this code review process with great enthusiasm. Raising the PRs, going an extra mile to get it reviewed, giving time to reviewing and leaving helpful comments.

But after the initial few weeks, as the enthusiasm for the process drops, feature development takes priority and the development pace grows due to business needs, the review process goes for a toss.

One of the main reasons behind this is that it becomes really hard to review commits. As the development speeds up, engineers churn out bigger and bigger commits that are hard to understand and review.

Thenceforth, people stop putting efforts into reviewing commits (just rubber-stamping it) and in some cases, it even goes down to no PR being raised and we go back to square 1.

Therefore, engineers should always try to produce small, meaningful and individual deployable commits to production. Initially, this may seem difficult when you try to split bigger commits into smaller commits and may end up in an odd state.

I have a pro tip that will help you to avoid this situation. Firstly, if you want better reviews for your commits, it is your responsibility to produce better "reviewable" commits.

The easy way to do so is by producing a commit stack which is like a story, or more analogous, like a Twitter thread. Further explanation below:

Most engineers already plan for the code architecture and design before developing a feature so here you can add an extra step to do a rough plan on commits. For example, your commit plan could look like

Individual commit for 1) Abstract class creation with 2 abstract functions 2) Derived class creation inheriting abstract class & providing empty impl. of overriding functions. 3) Method implementation of 1st overriding function 4) Method implementation of 2nd overriding function 5) Create objects and call the functions (may create separate commits based on context)

This is a very basic example to demonstrate the Commit plan. It gives an idea of how to produce isolated commits in a logical order which are easy to follow and understand.

Also, make sure that every individual commit compiles and pass tests.

My rule of thumb is that the Commit should not take more than 4-5 minutes to review. With practice, you get the idea about the number of lines of change in a 4-5 minute review. Shorter the commit, easier the review.

Not only you'll get better reviews but more reviewers will be willing to review your PR as it is easy to comprehend. Also, in case of reverting a commit, there are high chances you will be reverting only what is required and not more than that.

A reviewer should also feel free to comment "Too big to review".

If you follow these practices and keep few of the basics in mind like providing as much context as possible in the commit message to help the reviewer understand your commit better, things will definitely improve.

Lastly,

Be the Commit author, you wish to have as a reviewer.