Over the years, I curated a list of articles that give insights into how companies like Facebook, Google, or Netlify review code. On their engineering blogs, those companies share their code review values, or which tools they use. We also find insights into how other companies incorporate static or dynamic analysis, or how they deal with the problem of nit-picking.
In the following, you find summaries of the insights different companies share about their code review practices, as well as a link to the complete article.
Auth0
The code review guide of Auth0 focuses on the automation aspects, and also gives clear indications which quality criteria a pull request must pass before it is reviewed manually.
BitCoin Core
This guide examples how newcomers can help in reviewing pull requests in the BitCoin Core project and has an emphasis on distinguishing between core issues and nitpicking.
Facebook makes heavy use of static analysis tools. This researchy article goes into the details of how they scaled static analysis at Facebook using tools such as Infer and Zoncolan, and how to apply techniques similar to program verification in practice.
Gitlab
Gitlab’s engineers are very open about their desired engineering culture, their values, and how they do things. In this section of the Gitlab handbook, they outline their Code Review Values.
Google’s main principle is enabling lightning-fast code reviews. How Googlers achieve a code review turn-around time of 4 hours, and what their practice and policies are like are detailed in this article about code review at Google. Google’s official code review guidelines also state when they consider code good enough, or what to do when there is a conflict.
Microsoft
Microsoft does not have one way to do code reviews. Instead, teams or divisions review code depending on their specific needs, requirements, processes and constraints. Yet, Microsoft developers have a few best code review best practices that prove helpful to enable fast and effective code reviews independent of the system developers work on or the engineering processes they employ.
Netlify
Netlify describes how they use specific words to indicate the severity of the issues raised during code reviews. They use something they call the “feedback ladder”, which encodes severity in form of a “stone” metaphor. In their case, “sand” for example would indicate a minor issue that you can or cannot address during code reviews, and “rock” indicates a major issue you surely should work on.
Netflix
Netflix describes how they review tests and test outcomes during pull requests, as well as how they worked on improving their confidence in test results.
New Relic
New Relic had a team with very experienced engineers that soon turned on each other during code reviews. Passive-aggressive communication dominated the code reviews. After several people even left the team, they decided to refine their code review process from the ground up. They specified who is responsible for what, and require the code reviewers to separate subjective and objective code review feedback by labeling it “blocking” or “non-blocking”.
Palantir
Palantir describes how they do code reviews, in a guide that explains why Palantir does code reviews, when they do code reviews, and how they prepare and perform code for review, and also gives some code review examples.
Quora
Quora describes how they use post-commit reviews to increase speed. It’s common practice at Quora to push code without review (several times a day) to production. The rule of thumb is that this code should be reviewed within one week, but most of the code is reviewed within 1-2 days after it went live into the production system.
PayPal
PayPal developers outline their take on code reviews. The most interesting part of their guide is their focus on learning and mentoring. In fact, code reviews at PayPal are seen as free career improvement training.
Plaid
At Plaid, the Code Review Culture aims to allow for learning and growth of all parties and ship healthy code.
Raycast
Raycast on the other hand describes how they do not do code reviews by default. They think that pull requests lead to distrust in the team, and that the code author should take full responsibility for their changes.
Shoptify
Shopify describes how small, coherent pull requests help them to not live in fear for several months.
Software Improvement Group
The Software Improvement Group also outlines how they use Gitlab to do code reviews, and which rules and policies they incorporate in their code review practice.
Squarespace
Squarespace published about their code review culture in a two parts blog article: Code Review Culture PartPart 1 + Code Review Culture Part 2
Contribute to this list
If you have an article you think should be added, please open a PR here, or send it to me via email. Thanks.
