Code reviews are one of the most underrated skills in software engineering. Everyone does them, but few people think deeply about how they do them.
Here's my approach—developed over hundreds of PRs and plenty of mistakes.
The Goal Is Learning, Not Gatekeeping
The worst code reviews are the ones that feel like an exam. Someone's judging your work, you're defensive, and the whole thing becomes adversarial.
I try to approach reviews differently: my job is to help you ship better code and learn something in the process. If you walk away from my review having learned nothing, I've failed—even if the code gets merged.
What I Look For (In Priority Order)
1. Does It Work?
This sounds obvious, but it's the foundation. I'll pull the branch locally if the change is significant. Reading code on GitHub is one thing; actually running it catches a different class of bugs.
2. Is It Safe?
Security and data integrity issues get flagged immediately. These are non-negotiable:
- SQL injection vectors
- Unvalidated user input
- Auth bypasses
- Data leaks
I don't care how elegant the code is if it's exploitable.
3. Is It Maintainable?
This is where most review time goes. Questions I ask:
- Will someone understand this in 6 months?
- Are the abstractions helping or hiding?
- Is there unnecessary complexity?
- Are edge cases handled explicitly?
4. Is It Consistent?
Following existing patterns matters. If the codebase uses one style and you introduce another, that's friction for everyone who comes after. Consistency beats cleverness.
5. Is It Tested?
Not "does it have tests" but "do the tests actually verify the behavior." I've seen plenty of tests that pass but don't test anything meaningful.
How I Give Feedback
Be Specific
❌ "This is confusing"
✅ "The variable name temp doesn't tell me what it holds. Maybe userSessionData?"
Explain Why
❌ "Use a guard clause here" ✅ "A guard clause would reduce nesting and make the happy path clearer"
Distinguish Blockers from Suggestions
I use labels:
- Blocker: Must fix before merge
- Suggestion: Would be nice, take it or leave it
- Question: Not a request, genuinely curious
This prevents bike-shedding on minor style preferences while making sure real issues get addressed.
Praise Good Work
If someone did something clever or clean, I say so. Code review shouldn't just be about finding problems.
The Hardest Part
Knowing when to approve.
There's always something you could improve. But at some point, the code is good enough to ship and any further polish is diminishing returns.
My rule: if I don't have blockers, I approve. Suggestions can happen in follow-up PRs. Perfect is the enemy of shipped.
One Last Thing
The best code reviews happen when there's mutual respect. I'm not trying to prove I'm smarter than you. I'm trying to help us both ship something we're proud of.
That mindset changes everything.
This is part of my process series—how I actually work. More at /posts.