A book from Curtis Einsmann:
Software engineers engage in code reviews daily. Think about how much time you spend reviewing code, writing code that will be reviewed, or addressing code review feedback. There's no denying it: if you master code reviews, you'll level up fast.
This book is the complete guide to this critical process.
Coming soon! Subscribe for launch announcements, book samples as they're written, and video lessons.
Hi, I'm Curtis. In my early career, I struggled with code reviews. I've authored and reviewed over 1500 code reviews. During my six years at Amazon Web Services, I was a course instructor and mentor to dozens of software engineers. If you loved my writing on how I review code, or how I craft beautiful code, or how developers can level up, you're sure to love this book.
In 2022, I launched a video course called Master the Code Review to help software engineers level up their skills. Over one thousand developers have taken it, and over thirty companies have leveraged the team license to train their software engineers. This book is an in-depth expansion of the content from that course.
I'm writing this book to help developers overcome challenges I faced in the past. In my early career at AWS, I struggled with code reviews. My Pull Requests got more than 50 comments, and took more than 7 reviews. When I was sent code to review, I felt paralysis by analysis. I didn't know what to look for, or how to give good feedback. Long story short — I improved, and leveled up. I went on to ship 550 PRs to production. In my last year at AWS, I shipped over 90% of them in the first review. I've reviewed over 850 PRs, and my code review feedback has helped my peers level up and earn promotions.
Over the years, I came to realize that a few aspects of code reviews are objective — finding flaws and defects. But most aspects are subjective — opinion based discussions around software quality and readability. Succeeding in an opinoinated environment like code reviews takes specific soft skills, social skills and technical skills. I learned them the hard way, and now I'm sharing what I know.
This is an opinionated book by yours truly. I have first-hand experience on the topics I cover. You won't find this information in code review documentation or guidelines you've seen anywhere else.
PR comments shouldn't be personal, or vague.
— Curtis Einsmann (@curtiseinsmann) April 26, 2021
❌ "You didn't check for a null value."
✅ "This input value could be null, causing a server error. If null, a client error should be thrown."
The second:
- targets the code, NOT the person
- is clear about a suggested improvement
When you comment on a code review, there's a person on the other side.
— Curtis Einsmann (@curtiseinsmann) May 10, 2022
Be kind, so they respect your opinion. Be clear, so they know how to fix it. Be convincing, so they understand your reasons.
Hold high standards, but don't forget to build relationships.
Amazing thread with many tips by @curtiseinsmann on how to be effective with Pull Requests. https://t.co/S7GNNk9f82
— Thiago Ghisi (@thiagoghisi) February 17, 2022
A non-exhaustive list of what to look for in a code review:
— Curtis Einsmann (@curtiseinsmann) July 7, 2022
Does it work?
- Flaws
- Risks
- Testing gaps
- Over-engineering
- Behavior changes
Is it maintainable?
- Intent
- Naming
- Abstractions
- Conventions
- Organization
First group: objective
Second group: subjective
This is a great thread from @curtiseinsmann about how to review PRs well. 👍💪 https://t.co/qChtBNW8qv
— Jordan Hall 💻 (@DivineOmega) October 19, 2020
A great code reviewer:
— Curtis Einsmann (@curtiseinsmann) September 28, 2021
1️⃣ Catches flaws
2️⃣ Comments the code, not the person
3️⃣ Has high standards
4️⃣ States a reason why
5️⃣ Recommends a fix
6️⃣ Doesn't block urgency
7️⃣ Establishes paradigms
8️⃣ Uses linters for style
9️⃣ Gives praise
🔟 Is pragmatic, not a perfectionist
This is gold. I’ve seen these signs in every org. There are ways to address every single one, but you have to call it out first. https://t.co/ZoyKIutEOk
— Mitra Raman (@ramannoodlez) January 19, 2022
A common mistake of developers new to a "tech lead" role: trying to perform every code review. They're concerned that something will break if they don't.
— Curtis Einsmann (@curtiseinsmann) February 15, 2022
But reviewing every pull request isn't feasible, and doesn't scale.
What to do instead? Here's what I've learned: 1/8