A few years ago, I left a code review feeling… weird.
The code worked.
Tests were passing.
But the comments?
“This is wrong”
“Bad approach”
“Rewrite this”
No explanation.
No context.
Just judgment.
Nothing was technically incorrect.
But something was off.
That’s when it clicked:
Code reviews aren’t just about code, they’re about communication.
And done poorly, they don’t improve the codebase, they just slowly damage the team.
TL;DR
- Great code reviews focus on improving the code, not judging the developer.
- The difference is in how feedback is framed, not just what is said.
- Healthy teams optimize for clarity, context, and collaboration, not ego.
Table of Contents
- Why Code Reviews Go Wrong
- What Great Code Reviews Actually Do
- 1. Focus on the Code, Not the Person
- 2. Explain the Why, Not Just the What
- 3. Turn Judgments Into Questions
- 4. Avoid Bike-Shedding
- 5. Balance Speed and Depth
- Real Example: From Harsh to Helpful
- How to Handle Receiving Feedback
- Practical Team Agreements
- Final Thoughts
Why Code Reviews Go Wrong
Most developers don’t want to give bad feedback, but code reviews often become tense anyway.
Why?
Because they sit at the intersection of:
- ownership (“this is my code”)
- identity (“this reflects my skills”)
- time pressure (“we need to ship”)
Add a bit of unclear communication, and things escalate quickly.
What starts as feedback becomes criticism.
What should be collaboration becomes friction.
What Great Code Reviews Actually Do
A good code review doesn’t just catch bugs.
It does three things:
- improves the code
- shares knowledge
- strengthens the team
If one of these is missing, something is off, especially the last one, because a team that avoids reviews or fears them will never move fast in the long run.
1. Focus on the Code, Not the Person
This sounds obvious, but small wording differences matter a lot.
Compare:
This is wrong
vs
This logic might lead to edge cases when the input is empty
The first feels like judgment.
The second feels like collaboration.
A simple shift helps:
👉 describe the problem, not the person
Instead of:
- “you did this wrong”
Try:
- “this approach could cause issues because…”
It’s a small change, but it completely changes how feedback is received.
2. Explain the Why, Not Just the What
One of the most frustrating things in code reviews is vague feedback.
Refactor this
Why?
What’s the problem?
What’s the goal?
Without context, the comment becomes noise.
Good feedback always answers one question:
Why does this matter?
For example:
This works, but extracting this into a function could make it easier to test and reuse
Now the author understands:
- the intent
- the benefit
- the trade-off
And can make a better decision.
3. Turn Judgments Into Questions
When in doubt, ask.
Questions are powerful because they:
- invite discussion
- reduce defensiveness
- uncover context you might be missing
Instead of:
This is over-engineered
Try:
Do we need this level of abstraction here, or could a simpler approach work?
Same concern.
Completely different outcome.
Sometimes, you’ll even realize the original author had a valid reason.
4. Avoid Bike-Shedding
Not all feedback has the same weight, but many reviews treat everything equally.
You end up with long threads about:
- variable names
- formatting
- personal preferences
While more important issues get less attention.
This is called bike-shedding and it kills productivity.
A simple rule helps:
👉 focus on what impacts:
- correctness
- readability
- maintainability
Leave the rest to:
- linters
- formatters
- team conventions
Your energy is limited, so use it where it matters.
5. Balance Speed and Depth
There’s a tension in every code review:
- go deep → better quality
- go fast → better velocity
Great teams don’t pick one, they balance both.
Some practical ways:
- keep PRs small
- review early, not just at the end
- avoid “mega reviews” with 1000+ lines
Because the larger the change, the harder it is to review well.
And the easier it is for issues to slip through.
Real Example: From Harsh to Helpful
Let’s take a real-style example.
❌ Harsh
This is messy. Refactor it.
This creates:
- confusion
- frustration
- back-and-forth
✅ Helpful
This works, but it’s a bit hard to follow due to the nested conditions.
What do you think about extracting this part into a separate function? It might make the flow easier to read and test.
Now we have:
- context
- suggestion
- collaboration
Same intent, much better outcome.
How to Handle Receiving Feedback
Giving feedback is only half of the equation.
Receiving it matters just as much.
A few things that help:
- assume positive intent
- ask for clarification if something is unclear
- don’t take comments personally
- push back when needed, but with context
A good code review is not about agreeing on everything.
It’s about reaching a better solution together.
Practical Team Agreements
The best teams don’t leave this to chance.
They define how reviews should work.
A few simple agreements can make a big difference:
- “Explain the why” is mandatory
- Prefer questions over judgments
- Focus on high-impact issues first
- Keep PRs small and focused
- No ego in discussions
These are small rules, but they create a much healthier environment.
Final Thoughts
Code reviews are one of the most powerful tools a team has, but only if they’re done right because bad reviews don’t just slow down development, they create friction, frustration, and eventually silence.
Great reviews do the opposite:
- They improve the code.
- They spread knowledge.
- They build trust.
And in the long run, that’s what makes a team truly fast.
If this resonated with you:
- Leave a ❤️ reaction
- Drop a 🦄 unicorn
- Share the best (or worst) code review you’ve experienced
And if you enjoy this kind of content, follow me here on DEV for more.
Top comments (0)