English Phrases for Disagreeing Politely in Code Reviews
Disagree without friction in code reviews: softening language, questions over commands, the suggestion phrasing, and how to push back firmly when it really matters.
Code review is where many cross-team frictions begin — not because of the code, but because of the words. A comment that feels neutral to you can read as an attack to a non-native colleague, and vice versa. This guide gives you English phrasing that lets you disagree clearly while keeping the relationship and the pull request moving.
Why Tone Matters More in Writing
Spoken disagreement is softened by your face and voice. In a written comment, the reader has only the words. A blunt “This is wrong” lands far harder on a screen than in conversation. The goal is not to be vague — it is to be clear about the code while staying warm about the person.
Use Questions Instead of Commands
Questions invite a response; commands invite defensiveness.
| Command (harsh) | Question (collaborative) |
|---|---|
| “Move this to a service." | "What do you think about moving this into a service?" |
| "This will leak memory." | "Could this hold the connection open if the loop throws?" |
| "Don’t use a global here." | "Is there a reason this needs to be global?” |
“I might be missing context here — what’s the reasoning behind caching this on the client rather than the server?”
The phrase “I might be missing context” signals humility and often surfaces a good reason you hadn’t considered.
The “Suggestion” Pattern
Many teams distinguish blocking comments from optional ones. Make the difference explicit in English:
- Nit: “Nit: I’d rename
datatouserRecordsfor clarity — non-blocking.” - Suggestion: “Suggestion: we could extract this into a helper, but happy to leave it.”
- Question: “Question: does this handle the empty-array case?”
- Blocking: “Blocking: this query isn’t parameterised, which opens an SQL injection risk.”
Labelling your comments tells the author what they must address and what they may ignore.
Softening Phrases That Keep Things Light
“This is looking good overall — just one thing I wanted to flag.” “Mostly a style preference, so feel free to push back.” “I could be wrong, but…” “Have you considered…?” “What would you think about…?”
A small dose of softening goes a long way. Overusing it, however, makes you sound unsure — reserve the gentlest phrasing for genuinely optional points.
When You Need to Push Back Firmly
Sometimes politeness is not enough — a security flaw or a correctness bug must not merge. You can be firm and still respectful.
“I don’t think we should merge this as-is. This path allows unauthenticated users to read other accounts’ data, which is a security issue we need to resolve before release. Happy to pair on a fix if that’s useful.”
Notice the structure: clear refusal, specific reason, and an offer to help. Firmness without an explanation feels like a power play; firmness with a reason feels like care for quality.
Disagreeing With a Senior Reviewer
If you are the author and disagree with feedback, defend your decision with evidence, not ego.
“Thanks for the review. I chose this approach because the alternative added a round-trip on every request — here’s a benchmark. Open to changing it if I’ve misjudged the trade-off.”
“That’s a fair point. Could you say more about what you’d expect to break? I want to make sure I understand the concern before I change it.”
Asking the reviewer to “say more” turns a standoff into a discussion.
Phrases to Avoid
| Avoid | Why |
|---|---|
| ”Obviously this is wrong." | "Obviously” implies the author is foolish. |
| ”Why would you do this?” | Reads as an accusation, not curiosity. |
| ”Just do X." | "Just” minimises real complexity. |
| ”Everyone knows…” | Alienates and shames. |
A simple fix: replace “you” with “this code” or “we”. “You forgot the null check” becomes “This is missing a null check” — same information, no blame.
Closing a Review on a Good Note
“Nice work on this — the test coverage is great. Just the one blocking comment on the auth check, then I’m happy to approve.”
Ending with appreciation and a clear path to approval leaves the author motivated rather than deflated.
Disagreeing well in code reviews is a craft. Lead with questions, label what is blocking, soften the small stuff, and stay firm with a reason when it counts. Do this consistently and your reviews will become something colleagues look forward to rather than dread — which is, in the end, how good code actually gets shipped.