Great code reviews - the superpower your team needs

Lessons from Shopify

  • Keep your pull requests small (200-300 lines, or one single concern) so the reviewer won’t procrastinate or be interrupted and can dive deeper, yet respond to you faster. This way, you will also get more independent review units and therefore better quality review, affect fewer people and need to call on fewer domains of expertise, make it easier to identify problems for rollbacks, and separate the easy stuff from the hard.
  • Use work-in-progress (WIP) or draft pull requests (PR) to elicit early feedback that validates your choice of algorithm, design, API, etc., to ensure you are heading in the right direction before you start to build. This way you don’t waste time on documentation and details if you got it wrong.
  • When you are the reviewer, follow the principle of strong opinions loosely held, and focus on the code rather than the person. As a reviewer, take co-ownership of the code, frame comments as suggestions rather than instructions, and also offer positive feedback. As an author, assume the best intention rather than taking comments personally.
  • Pick the right person as reviewer: someone with context on the feature or component you are building, someone with strong skills in the language, framework or tool you use, someone with opinions on the subject, someone who cares about the outcome of your project, someone who needs to learn about this (in case of a junior reviewing a senior’s code).
  • Use a PR template where the description includes why the PR is necessary, who benefits from this, what can go wrong, what other approaches you considered, why you settled on this solution, and what other systems it can affect.

Full post here, 10 mins read