I’ve code reviewed over 750 pull requests at Amazon. Here’s my exact thought process.

Disclaimer: I’m not representing Amazon in any way. Opinions written here are strictly my own.

I’ve code reviewed over 750 pull requests in my 5-year software engineer career at Amazon. As my team’s tech lead I provide insightful feedback and encourage a high code quality bar.

But as a junior engineer I was a poor reviewer. I didn’t know where to start, what to look for or how to comment. I gave useless comments on style. I rushed through reviews giving the classic “LGTM!” after missing obvious flaws.

What follows is my thought process on how I review pull requests (PR’s).

I understand why code reviews matter.

Code reviews are an excellent coaching opportunity. Insightful feedback accelerates learning and growth.

They’re also an excellent learning opportunity for the reviewer. Every engineer solves problems in their unique way. Reviewing code exposes me to problem solving strategies I can leverage later.

I’ve taken the time to learn programming principles.

I’ve also read counterarguments to these principles. I understand that they’re guidelines, not rules. They work in some contexts but not others.

The most important questions are: does it work? Is it easy to maintain? Will we be able to understand it 2 years from now?

I review the PR slowly.

I pretend there’s a flaw hidden in the code; I’m the detective.

I start with the crux.

I start reading. I write comments as I go, knowing I’ll need to fix them later.

I read randomly until I achieve deep understanding.

Every line of code is a puzzle piece.

I often end up reading the same code 3, 4, even 5 times. I read until the entire puzzle forms in my brain.

I read class by class.

I ideate important edge cases as I read the implementation. I ensure these edge cases are covered when I read the test code.

I comment with kindness.

I leave at least one positive comment. (I sometimes forget to do this; I shouldn’t.)

I make myself available for verbal discussions if that’s desired.

I comment with accuracy.

I don’t leave ambiguous comments. Each comment explains:

  1. The problem with the code.
  2. The reason why I perceive it to be a problem.
  3. My recommendation for how the author can resolve it.

I leave style decisions up to the automated formatting tools.

I approve when the PR is good, not perfect.

But I hold my teammates to a relentless high standard. I give a [kind, accurate] comment even with minor confusion. I hold my authored PR’s to the same standard.

Some teammates have a proven track record of delivering quality, functional code. I understand these teammates deserve leniency. I’m not as thorough with these reviews, because I don’t need to be.

I seek feedback for whether I’m reviewing well.

But these are difficult to measure. As is measuring whether I’ve performed a good review.

I seek feedback from other engineers to understand if I’ve been helpful. I understand that I’ll improve as I perform more reviews.

How do you review pull requests? Does your thought process differ from mine? I’d like to hear it!

Like this article? It started as one of my viral Twitter threads. Follow me on Twitter, where I’m sharing soft skills for software engineers.

Lead software engineer at Amazon Web Services. Opinions mine. All stories free. Follow me on Twitter for more: https://twitter.com/curtiseinsmann