How to Get Developers to Care About Code Reviews
You can't guilt trip your way into a better engineering culture.
Last week I wrote about how code reviews are for humans—not robots, not gatekeeping, not checkbox theatre. (Code Reviews Are for Humans).
This post is about what happens when your team…doesn’t care. Like, technically you do code review. There’s a process. There’s a checklist. Comments happen.
But it’s performative. Hollow. No one’s learning, no one’s talking, and “LGTM” is the most honest thing anyone’s written in weeks.
If this sounds familiar, your team doesn’t have a code review problem—you’ve got a culture issue wearing a GitHub disguise. The review process has become a hollow ritual, and trying to fix it with generic calls to "care more about quality" is like duct-taping empathy to a sprint board and calling it leadership.
So let’s talk about why devs stop giving a damn about reviews—and what it actually takes to help them start again. Spoiler: it’s not a Jira ticket.
The Code Review Apathy Spiral
Nobody wakes up thinking, “Today I will do the absolute bare minimum to get this PR approved.” So what happens?
It usually starts small:
A PR goes up that’s 450 lines and touches 19 files. Nobody reviews it because it’s intimidating.
A few people leave one-line comments about spacing and semicolons. Nothing meaningful.
The author addresses the comments, gets approved, and merges.
Next time, they expect the same pattern. Review becomes a formality, not a conversation.
Multiply that by six months and a few dozen sprints, and congrats: 🎉 you have a ritual with no soul.
Why would anyone care about something that’s never been modeled as valuable?
Why Developers Stop Caring (and Why It Makes Total Sense)
1. Massive PRs that no one wants to read
You drop 500 lines of code and expect someone to give detailed, thoughtful feedback in 15 minutes? Please.
2. Reviews that offer nothing but nitpicks
Nothing says “this team values learning and collaboration” like a drive-by comment about using single quotes instead of double.
3. The incentives are all wrong
If you're measured by tickets closed, not code quality or team health, guess what gets de-prioritized?
4. Reviews are inconsistent and unclear
Every reviewer has different preferences, and none of them are documented. What passes one week gets blocked the next. It’s like a coding reality show with rotating judges.
5. Feedback disappears into the void
Ever leave a thoughtful review and get zero response? No comments, no changes, just crickets and a merge? Yeah, that kills motivation fast.
6. It doesn’t feel safe
If the review process has ever been used to humiliate someone or "win" a technical debate, people will avoid it like the plague.
7. ChatGPT reviews everything now
If your org is leaning on AI-generated comments and calling that a code review process... congrats, you've outsourced not just the thinking but the caring.
What Doesn’t Work
“Let’s just be better about reviews.”
“We should all try to care more.”
“Can we please review PRs faster.”
None of these solve the actual problem. They’re just vague appeals to feelings.
You don’t fix disengagement with optimism. You fix it by changing the system so caring is safe, rewarding, and useful.
What Actually Works
1. Make It Safe
If you want people to participate, they have to know they won’t get wrecked for doing so.
Model curiosity: Ask “Why did you approach it this way?” instead of “Why didn’t you do X?”
Normalize not knowing: Encourage reviewers to say “I’m not sure, but this seems off to me.”
Shut down toxic comments, period. There’s no room for condescension or gotchas in a review.
2. Make It Visible
Recognize good reviewers. Not just the person who merged the most PRs, but the one who left helpful, thoughtful feedback.
Shoutouts in standup or retro
Encourage authors to thank reviewers publicly
Call out learning moments when they happen
3. Make It Sustainable
If the review process is painful, people will avoid it.
Encourage small, focused PRs
Use templates and checklists to set clear expectations
Block calendar time for code review—don’t just “fit it in”
4. Make It Collaborative
Reviewers shouldn’t feel like submitting homework to an invisible judge.
Pair review big PRs together
Leave comments that start conversations, not just directives
Be willing to jump on a quick call instead of writing a novel in the comments
If Nobody Cares, It’s Not a People Problem. It’s a System Problem.
When code review becomes a soulless checkbox, it’s because the system has slowly trained everyone to stop caring.
You don’t fix that by mandating empathy or assigning blame. You fix it by building an environment where giving a damn is actually worth it.
If you’re a lead or a manager, your job isn’t just to “enforce” code review. It’s to build a system where:
People know what’s expected
Feedback is valued
Collaboration is normal
And reviews make the work better, not just more delayed
TL;DR:
If your team doesn’t care about code review, it’s not because they’re lazy. It’s because the process has taught them not to care.
Change the process. Model the behaviour. Make it safe. Make it visible. Make it collaborative.
Then sit back and enjoy watching your team start to give a damn again.