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!

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with Curtis Einsmann

Curtis Einsmann Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @curtiseinsmann

21 Sep
When I was a jr engineer at AWS my PR’s went through 100+ comments and 7+ revisions due to poor code quality. The friendly, helpful feedback helped me improve.

Now as a mid-level I tend to ship code in <= 2 revisions with minimal comments.

Here’s how I’m doing it. 🧵👇
1️⃣ I understand why code quality matters.

We read code 10x more than we write it. Our code must be understandable so our team can maintain and add features.

Poorly written code causes PR churn, which results in delayed delivery and can block other team members.

2️⃣ I take on small tasks.

A good PR starts before any code is written. The task should be small, resulting in an easily reviewable PR.

Bad task: UpdateWidget API

Better: split into 4 separate tasks - UpdateWidget model; AuthN/AuthZ; input validation; implementation

Read 12 tweets
31 Aug
My first ever Medium story got 22.5k views in its first 3 weeks.

What I did right ✅ and wrong ❌.

THREAD. 🧵 👇🏽 Image
✅ I had a story to tell.

I did something cool in real life. This is important.

I had a unique journey at Amazon. I overcame my technical incompetency to achieve success.

I wanted to help people overcome similar challenges.
✅ I told the whole story.

People read stories to apply experience to their life.

I was vulnerable. I used quantitative metrics (“80+ comments”). I showed my feelings (“face turned red”).

I provided the mindset I used to overcome struggles. Specific and actionable.
Read 13 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!