#code review
8 posts

Great code reviews - the superpower your team needs

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.
Read more

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

Tips for more helpful code reviews

While suggesting changes include code samples. Treat a code review as a public conversation, and remember even experienced developers can gain from ideas on implementation.
Read more

Tips for more helpful code reviews

  • Consider the impact of your words. If necessary, rewrite comments for empathy and clarity both.
  • Elaborate on your concerns to be more specific and to avoid ambiguity, even if it sounds more verbose.
  • While suggesting changes include code samples. Treat a code review as a public conversation, and remember even experienced developers can gain from ideas on implementation.
  • Include a link to relevant documentation when referencing a function, commit or pull request. For concepts, link a blogpost. Make it easy for the author to get to things you reference with a single click.
  • Offer to chat in person or on video call for clarifications, and volunteer to pair up and collaborate on any suggested changes.

Full post here, 5 mins read

Good code reviews, better code reviews

Questioning the necessity & impact of code changes in the context of your overall system. Look at abstractions introduced and aim for doing a contextual pass.
Read more

Good code reviews, better code reviews

  • You can make code reviews better by questioning the maintainability, necessity & impact of code changes in the context of your overall system. Look at abstractions introduced and aim for doing a contextual pass.
  • Any good code review avoids opinionated comments/statements. You can make code reviews better by focusing on being empathetic and all-round positive, kind and unassuming.
  • Good reviewers leave as many comments and questions as are needed, and prefer connecting with the author in-person, while better reviewers will proactively reach out to the person to avoid any misunderstandings in the first place.
  • You can have better coder reviews by looking beyond the errors and trying to figure out the underlying issue.
  • Companies with good code reviews ensure that everyone takes part in the code review process. Companies with better code reviews ensure that code just doesn’t make it to production without reviews.

Full post here, 8 mins read

How to do good code reviews

Set measurable goals and capture metrics. Look for code that is repeated, non-modular, or flouting standard conventions.
Read more

How to do good code reviews

  • Set measurable goals and capture metrics, but do not set too many. Good code must work as intended, have high readability, and perform optimally.
  • Ask deep questions and confirm your understanding at each step, until your knowledge of the code is as good as the developer’s.
  • Address everything you may think relevant, not just what you were told.
  • Look for code that is repeated, non-modular, or flouting standard conventions.
  • Avoid reviewing code for more than 60 minutes or more than 400 lines at a time. Increase the frequency of reviews so you can take time to identify the best solutions.

Full post here, 6 mins read

How to be a better code reviewee

Write tests before committing the code. Submit code and then test it together for review. Use descriptive commit messages. Group similar changes with a description for each group.
Read more

How to be a better code reviewee

  • Write tests before committing the code. Submit code and then test it together for review.
  • Use descriptive commit messages. Group similar changes with a description for each group.
  • Limit the code to review so that your reviewers are not too overwhelmed and have time & patience to consider the logic & depth of your code.
  • Don’t take comments personally. Provide resources and arguments to defend your choice if you believe you are right.
  • Take difficult problems or conflicting views offline. You will achieve consensus faster by discussing in person than over comments.

Full post here, 5 mins read