Code Reviews: A How to Guide
June brings sunny vibes in the PNW as I dive into sharing my code review strategies!
We are in one of the best times of the year in the Pacific Northwest. It's warm and sunny, but only around 75F degrees (around 24C for the metric users out there). Everything is still lovely and green from the very wet winters we get.
I spent most of this weekend planting flowers and cleaning up the yard, and it was incredible. I'm from a part of the world where experiencing sunshine feels like you're on party drugs, so June feels like quite the party!
Highlights
Things I've been doing on the internet
I haven't done a ton on the internet recently, since I recently went on vacation. I'm getting back into the groove, though, and it feels good to be back!
- Podcast: Overcommitted Ep. 9 | Learning how to learn
- Illustration:
Things I've enjoyed on the internet this week
If you've got something you want me to read and feature in this newsletter, send it to me at brittany@balancedengineer.com!
- Book: Software Engineering After the Vibe Shift
- This is a book by Sean Goedecke, who is one of my colleagues at GitHub! He has done a ton of blog posting recently and he put a bunch of those blog posts together in a book. I read this on the plane while heading back from Florida and it was amazing. I love this idea of linking blog posts together in this way, and it was a great way to catch up on posts that I've missed!
Onto the content!
It's a new month, so it's time for a new topic! This month we're diving into code reviews.
June Theme: Code Reviews
Reviewing code is one of the highest-impact activities that senior+ engineers can take on. It helps your colleagues get unblocked AND makes the codebase better. Plus it usually takes much less time than writing new code. What a win for everyone involved.
Today I want to share how I approach code reviews—a process I developed after years of learning the hard way.
Why this perspective matters
I still remember the very first time I was asked to review someone else's code. It was shortly after I started my first gig as a software engineer, and I had absolutely no clue what I was doing. What made it worse? None of my teammates knew how to do it either! It was definitely the blind leading the blind.
I've noticed that code reviews are something no one ever teaches you systematically. There's no handbook, no training session—you're just expected to figure it out. As a result, I've learned by watching colleagues approach reviews differently, picking up techniques through trial and error, and honestly making plenty of mistakes along the way.
My systematic approach
After years of refining my process, here's how I tackle every code review:
1. The big picture pass
I start by understanding the context. I'll read the PR description and any linked issues to grasp the problem being solved. Then I'll scan the list of changed files to see which areas of the codebase are affected.
Finally, I'll think about how I would approach this problem to ensure I understand what needs to be accomplished.
2. The logic pass
Next, I read through each change to verify the code makes sense. This is where I step through the implementation to ensure the logic works as expected and actually solves the stated problem.
3. The potential problems pass
After confirming the logic is sound, I look for issues that could cause future headaches. Depending on the codebase, I consider:
- Could this introduce security vulnerabilities?
- Are there accessibility implications?
- What happens with edge cases or unexpected data?
- Could this break existing functionality?
4. The future-proofing pass
Finally, I evaluate long-term maintainability:
- Will someone understand this code in six months?
- Are there performance implications that could become problems at scale?
- Are the important code paths covered by tests?
- Should any documentation be updated alongside these changes?
Prioritizing my feedback
Once I've gathered my thoughts, I review all my comments to assess their importance. I'll mark suggestions that are preferences rather than requirements as "nit" (nitpick) so the author knows they're optional.
Unless something will cause significant problems, I almost always approve while reviewing. Most of my feedback consists of suggestions, and I'm never offended if someone chooses not to implement them.
Key lessons I've learned
Looking back on years of code reviews, a few principles have emerged:
The PR is a permanent record
If I don't understand something, I always ask. These questions become valuable documentation for future developers (including myself) who need to understand why certain decisions were made. Impact matters more than perfection
While suggestions are helpful, some feedback is more critical than others.
I focus my energy on catching bugs and security issues rather than style preferences that won't affect functionality.
Everyone needs their own checklist
I've developed my own mental checklist for code reviews, but yours might look different. What's important for your codebase? Are there recurring issues your team faces? Writing down what you look for can help identify blind spots and create more consistent reviews.
The goal isn't to catch every possible issue—it's to be a thoughtful safety net that helps your team ship better code while learning from each other in the process.
Have comments or questions about this newsletter? Or just want to be internet friends? Send me an email at brittany@balancedengineer.com or reach out on Bluesky or LinkedIn.
Thank you for subscribing. It would be incredibly helpful if you tell your friends about this newsletter if you like it! :)