Thread by @curtiseinsmann

I’ve reviewed over 750 PR’s at AWS. As my team’s tech lead I provide insightful feedback and enforce a high code quality bar.

But as a jr engineer I couldn’t review code. I didn’t know where to start, what to look for or how to comment.

Here’s how I review PR’s. 🧵 👇

1️⃣ I understand why code reviews matter.

They're an excellent coaching opportunity. Insightful feedback accelerates learning and growth.

Quality code strengthens readability and system understanding. This is a force multiplier for the team’s long term feature velocity.

👇

2️⃣ I’ve taken the time to learn programming best practices.

I understand principles like SOLID, DRY and KISS.

I’ve read the Clean Code book. I understand the importance of naming, small functions and logical control flow.

👇

3️⃣ I review the PR slowly.

Insightful feedback requires a deep understanding of the change. I prevent my eyes from glazing over a line of code I don’t 100% understand.

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

👇

4️⃣ I start with the crux.

I scan through the PR to find the critical piece of implementation. This could be the API entry point or the refactored data access layer.

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

👇

5️⃣ I read randomly until I achieve deep understanding.

I follow function calls. I jump around. I read existing code for context. 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.

👇

6️⃣ I read class by class.

This comes only after I achieve deep understanding.

I ideate unit tests as I read the implementation. I ensure the edge cases are covered when I read the test code.

👇

7️⃣ I comment with kindness.

I comment on the code, not the person. I avoid using “you” or “your.” I prefix nitpicks with “nit.” I phrase most comments as questions or suggestions.

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

👇

8️⃣ I comment with accuracy.

I write comments while reading. But I rewrite many of these comments after deep understanding.

Each comment explains the problem with the code, the reason why it’s a problem, and how the author can resolve it.

👇

9️⃣ I approve when and only when the PR is good enough.

I hold my teammates to a relentless high standard. I give a [kind, accurate] comment even with minor confusion.

But I understand perfection is a pie in the sky. I approve if it works, and/or it only has a few nitpicks.

👇

The above steps 👆 will help you become a better PR reviewer. They’ll deepen your understanding of the code and help develop other team members.

What's your thought process during code reviews? I’d like to hear it!