If you want to build a high-velocity engineering team, code reviews matter more than people think. Not because they’re a place to play “gotcha,” but because they’re a force multiplier: they improve code quality, transfer knowledge, reduce bugs, and make your team faster.
But only if you do them well.
A slow or sloppy code review does the opposite. It blocks progress, kills momentum, and creates resentment inside teams. I’ve seen both firsthand.
Here’s the framework I use (and teach) for reviewing code properly.
1. Start With a Quick Scan
Before reading a single line of code, zoom out.
Is the commit message correct, descriptive, and following the Conventional Commits format?
Do the title and description actually match the changes?
Is the PR the right size, or is it trying to do five things at once?
Conventional Commits make it extremely obvious what changes are important (feat:), what’s a fix (fix:), and what’s just refactoring (chore:).
They also make rollback and commit-history navigation dramatically easier.
If the PR fails this step, stop and ask them to clean it up.
2. Check the Structure and Length of the PR
Good code should be readable at a high level.
Ask yourself:
Can I skim this PR and understand what it does?
Is it a reasonable number of files/lines?
Are there comments where comments are actually needed?
If you can’t understand the change by reading it top-to-bottom, something is off.
Either the code is too complex, the PR is too large, or the engineer hasn’t added context.
Every “I’m confused” moment is a future bug.
3. Look at Names With a Critical but Kind Eye
I don’t nitpick variable names for hours, but unclear names slow everyone down.
Look for:
Placeholder or temporary names left in by accident
Names that don’t match the domain
Names that force you to read the implementation to understand what’s going on
I generally leave these as nit or optional comments, but in some cases, its best to make them blocking, especially in the case of a placeholder or temporary name left in.
4. Examine Third-Party Integrations Carefully
Any time the code touches something outside your system, your scrutiny should go up:
API calls
Third-party SDKs
Authentication/authorization
Payment providers
Event systems
Notifications (email, SMS, push)
Look specifically for:
Retries (do they exist? are they safe?)
Timeouts
Logging (will you know what happened if it fails?)
Error handling
Idempotency
Most “high-severity” bugs don’t come from your own code. They come from how your code interacts with external systems.
5. Ask: “Is This the Best Way to Do It?” (But Don’t Be a Jerk)
You’re not trying to enforce “the perfect code.”
You’re trying to help your teammate ship something clean, maintainable, and reliable.
If there’s:
A simpler way
A standard library function
A well-known pattern
A built-in tool
Or a reliable open-source solution
…suggest it respectfully. This is usually not a blocking comment from me unless there is a clear reason to make it one. Everyone has their own idea of what perfect code looks like, and if we all insisted on it, no code would ever get shipped.
Not every PR needs to be elegant enough to frame, but if you have a better idea, share it.
Just don’t block or belittle. Shipping matters too.
6. Remember the Golden Rule: Don’t Be an Asshole
A good code review is not:
A critique of the engineer
A performance review
A place to flex knowledge
A chance to rewrite the PR in your style
It is:
A collaboration
A guardrail
A teaching moment
A chance to improve team velocity
Perfect code that ships late is worse for the business than good code that ships today.
Great engineering teams optimize for both quality and speed. Code reviews are where those two meet.
Good code reviews produce better engineers.
Great code reviews produce better organizations.
If you want a culture of shipping fast, building well, and learning continuously, this is where you start. If you made it this far, forward this to an engineer you think could benefit from these tips.
See you next week.
Arjay