We’ve all seen it.
A pull request with hundreds of changed lines gets approved with:
LGTM.
And somehow that counts as a review.
Weeks later, a bug shows up in production, and everyone wonders how nobody caught it earlier.
Often, the answer is simple:
People saw issues — they just didn’t want to sound too critical.
When Politeness Becomes Avoidance
Respectful communication is important. But many teams confuse respect with never challenging anything directly.
Comments become overly soft:
“Maybe we could possibly consider another approach…”
when what they really mean is:
This design has problems.
That kind of over-politeness turns important feedback into optional suggestions.
And optional suggestions are easy to ignore.
Good Reviews Need Friction
Great code reviews are not supposed to be effortless.
They should include questions like:
Why use this abstraction?
What happens under edge cases?
Does this create future maintenance pain?
That friction isn’t conflict.
It’s engineering.
Without it, reviews become typo checks instead of quality checks.
“LGTM” Isn’t Always a Review
Sometimes “Looks Good To Me” really means:
I skimmed it
I’m busy
I trust someone else reviewed deeply
I don’t want to start debate
That’s approval, not review.
And there’s a difference.
Direct Feedback Isn’t Rude
Strong feedback doesn’t need to sound harsh.
Instead of:
❌ This is bad design.
Try:
✅ This may couple concerns too tightly — can we rethink it?
Clear feedback improves code.
Vague feedback protects comfort.
Only one improves systems.
Final Thought
Code reviews were never meant to be therapy sessions where nobody risks discomfort.
They exist to challenge ideas and improve software.
Sometimes that means saying:
This shouldn’t merge yet.
And that’s not being difficult.
That’s doing a proper review.
Top comments (0)