Code Reviews That Don’t Suck – A Guide for Humans ?

Lomanu4 · 20 Май 2025

Introduction: The PR From Hell

We've all been there.

You spend hours crafting a pull request. You triple-check your logic, lint your code, and even write tests. You hit "Create PR" and wait. And then it happens:

// why did you even write it like this?

// use better naming.

// NAK.

No context. No solutions. Just passive-aggressive comments that feel like personal attacks.

Code reviews should be a collaborative safety net, not an emotional minefield. But more often than not, they spiral into cycles of frustration due to blame culture, vague feedback, and unchecked ego clashes.

The truth is: great code reviews aren’t just about code.
They’re about people.

Let’s explore how to make code reviews suck less—for everyone involved.

Core Principles of Effective Code Reviews

1. Psychological Safety

Code reviews thrive in environments where people feel safe to be wrong.

Frame feedback around the code, not the person.
Avoid blame or assumptions.
Encourage questions, not silence.

Bad:

This is completely wrong.

Better:

I think this might introduce a race condition. What do you think about using a lock here?

2. Clarity & Specificity

Generic comments are worse than no comments. Be clear, direct, and helpful.

Use concrete examples.
Point to documentation or patterns.
Suggest alternatives.

Bad:

Optimize this.

Better:

This loop runs in O(n^2). Could we use a hash map here to reduce it to O(n)?

3. Empathy & Tone

Would you say that to someone’s face in a meeting?

Mind your tone: neutral or kind wins.
Use "I" language: "I noticed...", "I wonder..."
Avoid exclamation marks unless you’re celebrating.

Bad:

Obviously, this is wrong.

Better:

I might be missing something, but could you explain why we need this check?

4. Focus on Goals

Every review should answer this: Does this change move us closer to our goals?

Prioritize readability, scalability, and security.
Don’t nitpick style if a formatter can do it.
Align feedback with the bigger picture.

Example Goals:

Reduce cognitive load
Prevent regressions
Support upcoming features

Practical Tips for Reviewers

1. Use the Sandwich Method

Start with something positive, suggest improvements, and close with encouragement.

Example:

Great job organizing this component—super clean! One thought: would using a custom hook simplify the reuse logic? Overall, solid work!

2. Ask Questions Instead of Commands

Turn feedback into collaboration, not confrontation.

"Did you consider using memoization here?"
"Would it make sense to extract this block into a utility?"

3. Set Time Limits

Don’t review code like you’re grading a dissertation.

Cap deep reviews to ~1 hour per day.
Prioritize critical logic over minor formatting.
Trust your linters and CI.

Practical Tips for Reviewees

1. Detach From Ego

Code is not an extension of your soul. Feedback is not rejection.

Be open to learning.
Assume good intent.
Breathe before replying.

2. Clarify, Don’t Clash

Misunderstood feedback? Ask for clarification.

"Hey, could you elaborate on what you mean by 'optimize this'?"
"Do you think this change conflicts with our current caching strategy?"

3. Automate the Obvious

Don’t waste human attention on spacing and semicolons.

Use Prettier, ESLint, etc.
Let CI catch regressions.
Keep reviews focused on meaningful discussions.

Make It Human, Make It Better

Code reviews are a powerful tool for growing engineers, improving codebases, and building better products. But only when they're done with empathy, clarity, and collaboration in mind.

Let’s stop treating them like battlegrounds and start using them as workshops.

What’s Your Worst Code Review Story?

Comment below or share this with your team. Let’s start a conversation about how we can all do better.

? Connect With Me On:

?