Our code reviews used to be the worst part of the week. Pull requests sat for days. Comments turned into arguments. People took feedback personally, defended their code like it was their child, and the whole thing felt less like collaboration and more like a slow-motion turf war.
Then we adopted one rule. Just one sentence, written at the top of our review guidelines. Within a month, reviews were faster, kinder, and — this surprised me most — the code got better.
I've since shared this rule with three other teams and it's done the same thing every time. It's almost embarrassingly simple. Here it is.
The rule that changed our team: every review comment must be labeled as one of three things — "blocking," "suggestion," or "nit" — and the author decides what to do with everything that isn't blocking. That one move separated "this must change before merge" from "here's an idea" from "tiny preference," ended the endless debates over trivia, sped up merges, and made feedback feel collaborative instead of combative. Clarity about severity fixed everything else downstream.
The problem with our old reviews wasn't laziness or bad people. It was ambiguity.
Every comment carried the same weight. "This variable name could be clearer" and "this will cause a data loss bug" looked identical in the thread — same gray comment box, same tone. So the author couldn't tell what they had to fix versus what was just an opinion.
That ambiguity created two equal and opposite failures:
And because nobody knew the severity, every comment became negotiable, which meant every comment became a potential argument. The reviews were slow and tense because they were unclear. Even the GitHub Octoverse reports, which chart how much of modern software now flows through pull requests, make it obvious how much leverage sits in getting this one ritual right.
Here's the entire system. Every review comment gets a prefix:
That's the whole rule. Three words. And then the crucial second half: the author has authority over everything that isn't "blocking." Suggestions and nits are theirs to accept or wave off, no justification required.
A code review isn't a gate where the reviewer holds the keys. It's two people making the code better, with one clear list of what actually can't ship.
The speed improvement came first and was dramatic. Suddenly authors could glance at a review and instantly see the one or two blocking items, fix those, and merge. The pile of nits no longer held the whole pull request hostage.
The tone improvement followed. Labeling a comment "nit" does something psychological — it signals I know this is small, I'm not going to fight you over it. That tiny act of humility defused most of the old tension. Reviewers stopped sounding like they were issuing demands.
And the quality improvement was the sweet surprise. Because "blocking" became rare and meaningful, people took it seriously. When someone wrote "blocking," everyone knew it was real. The signal stopped drowning in noise.
Here's the before-and-after we actually felt:
| Metric | Before the rule | After |
|---|---|---|
| Time a PR sat open | Often 2-3 days | Usually under a day |
| Arguments per review | Common | Rare |
| Real bugs caught | Inconsistent | Reliably |
| How reviews felt | Combative | Collaborative |
Whenever I share this, someone asks: "Doesn't giving authors authority over suggestions mean they'll just ignore good advice?"
In practice, no — and the reason is interesting. When you remove the obligation to obey, you also remove the instinct to defend. Authors who aren't being forced are far more open to actually considering a suggestion on its merits. People accept good ideas readily; they only resist being told what to do.
We found authors took more suggestions after the rule, not fewer. The pressure was gone, so the ego was gone, so the idea could be judged on whether it was actually good.
The "blocking" label is the safety net. Anything that genuinely must change still must change. The rule doesn't lower the bar on real problems. It just stops trivia from masquerading as a real problem.
Adopting a rule and having it stick are different things. What made it actually take hold for us:
It took us about three weeks to make it a reflex. After that, nobody wanted to go back. And it pairs well with modern tooling — when an AI assistant suggests a review comment, we label that too, because an AI nit is still just a nit. Treating review as the main event rather than a formality is also what changed once I tried coding with only AI for two weeks and saw how much rides on a careful reader.
The labels were the mechanism, but they triggered something bigger that I didn't fully appreciate until later. They changed how the team thought about ownership of code.
Before, a review felt like the reviewer passing judgment on the author — a superior approving an inferior's work. The dynamic was inherently a little hierarchical and a little adversarial, even between peers, because the reviewer held the merge button hostage over every comment. No wonder people got defensive.
By handing the author authority over everything non-blocking, we quietly reframed the whole interaction. The reviewer became an advisor offering input, not a gatekeeper issuing demands. The author stayed the owner of their work, responsible for it, free to weigh advice. That's a healthier relationship for adults, and the tone followed the structure.
Defensiveness in code review isn't a personality problem. It's a structure problem. People defend their work when they feel it's being taken from them.
Fix the structure — make it clear the author still owns the work and only genuine blockers are non-negotiable — and most of the personality problems evaporate. We didn't hire nicer people. We changed the incentives, and the same people got nicer.
The deeper lesson outlived this one rule. I used to think improving a team meant adding more process — more checklists, more required approvals, more gates. This experience taught me the opposite. The best process changes usually remove ambiguity rather than add control.
We didn't add steps to our reviews. We added clarity to the steps we already had. One word per comment. That's it. And it did more for our speed, our quality, and our morale than any amount of new tooling or mandatory ceremony ever did.
When something on your team feels slow and tense, the instinct is to add structure. Resist it. First ask: where is everyone confused about what actually matters? Usually the friction isn't a missing rule. It's an unspoken ambiguity that everyone is silently negotiating around, all day, at enormous cost. Name the ambiguity, and you often don't need the new rule at all.
Leading change like this is part of what the job becomes as you climb, which is the whole subject of the brutal truth about becoming a senior developer if you're growing into that kind of influence.
Q: What if the author and reviewer disagree on whether something is "blocking"? That's now a focused, productive conversation about one real thing, instead of a vague tug-of-war over everything. Disagreements about genuine blockers are healthy and rare. If it happens a lot, your "blocking" definition needs tightening.
Q: Doesn't this slow reviewers down, having to label everything? Barely — it's one word per comment. And it saves enormous time downstream by killing the back-and-forth. A few seconds of labeling prevents hours of argument. Easy trade.
Q: We're a tiny team. Is this overkill? It scales down fine. Even with two people, separating "this can't ship" from "just a thought" removes friction. Small teams often have the most tension per review because everything feels personal. The labels help there too.
Q: Does this replace having real review standards? No — it makes your standards legible. You still need to know what good code is. The rule just communicates severity clearly, so your standards land as collaboration instead of as commands.
Our code reviews were slow and tense because every comment looked equally urgent, so nobody knew what actually had to change. One rule fixed it: label every comment "blocking," "suggestion," or "nit," and let the author own everything that isn't blocking.
Clarity about severity turned out to fix the speed, the tone, and the quality all at once. The best process changes are usually this small.
So if your reviews feel more like battles than collaboration, ask: can your team tell, at a glance, what actually can't ship? If not, three little words might change everything.
No following, no network, no luck. Just an unglamorous system I ran for eighteen months. Here's exactly what I did.
I went from 200 to 11,000 subscribers without hiring anyone. AI didn't write my newsletter — it did everything around it.
I chased big, audacious goals for years and burned out every time. Then I built my whole life around wins so small they felt like cheating.
Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!