Code Review Culture: How to Give Feedback That Improves Code
I've sat on both sides of enough code reviews to notice a pattern: the teams that ship the most reliable code aren't the ones with the strictest reviewers. They're the ones where code review actually functions as a conversation instead of a gate someone has to get past.
The gate mentality is the root problem
When code review is treated purely as approval-seeking, something a developer has to survive to merge their work, the incentives get twisted. Reviewers rubber-stamp things to avoid conflict, or developers game the process by picking the reviewer least likely to push back. Neither produces better code. The review stops being about the code and starts being about clearing a hurdle.
I try to frame reviews, explicitly, as a second set of eyes on a shared problem, not a checkpoint one person has to pass and another has to guard.
Every comment should carry a reason
"This is wrong" tells someone nothing they can use next time. "This will fire a separate query per item in this loop, worth wrapping it in .Include() to batch it" tells them exactly what's wrong and why, and they'll likely catch it themselves next time without needing the comment repeated.
// Less useful:
Change this.
// More useful:
This creates a new HttpClient per request, which can exhaust socket
connections under load. Worth injecting IHttpClientFactory instead.
The extra sentence costs almost nothing to write and changes whether the feedback teaches something or just gets grudgingly applied and forgotten.
Separate "this will break" from "I would have done it differently"
Not every comment carries the same weight, and treating them all the same in tone flattens that distinction in a way that erodes trust over time. A correctness issue, a missing null check, an unhandled exception path, a genuine security gap, deserves a firm, clear comment. A stylistic preference deserves a much softer one, or sometimes no comment at all. I've seen reviewers who apply the same tone to both, and it trains people to either ignore all feedback as noise or become defensive about all of it, neither of which helps.
I try to be explicit about which category a comment falls into: "this will break under concurrent load" versus "small nit, feel free to ignore."
Ask questions instead of issuing verdicts, when you're not certain
If I don't fully understand why a decision was made, I ask rather than assume it's wrong. "What led you to this approach over X?" often surfaces a constraint I didn't know about, and it keeps the conversation collaborative instead of adversarial. Sometimes the answer reveals a genuine problem. Sometimes it reveals I was missing context. Either way, the question got there faster and with less friction than a confident, wrong correction would have.
Review the design before the syntax
Catching a missing semicolon or an inconsistent variable name matters, but it matters far less than catching a fundamentally wrong approach before it's fully built out. I try to review structure and approach first, ideally before a PR is even opened, in a quick design conversation, rather than only encountering a bad architectural decision after someone has spent two days implementing it in full.
Respond to reviews as quickly as you'd want your own reviewed
A PR that sits unreviewed for three days doesn't just delay one developer, it often blocks whatever depended on that work, and it quietly teaches people that code review is a bottleneck to route around rather than a normal part of shipping. I treat review turnaround as seriously as I treat my own deadlines, because from the other side of the review, it's exactly that.
The measure of a healthy review culture
The best signal I've found isn't review speed or comment count, it's whether people feel comfortable submitting work they're genuinely unsure about, without fear of the review turning into a personal critique. That comfort is what actually produces honest, catchable-early mistakes instead of code that's been polished defensively to survive review rather than to be correct.
