Phrasing critical feedback as a question or trade-off, explicitly separating correctness issues from style preferences, praising good decisions and not just flagging problems, and following up in person on anything that could read as harsh.
Published September 23, 2026
Directive (reads as a demand):
"This should use a HashMap instead of a List."
Question/trade-off (invites reasoning, leaves room for context you might be missing):
"Would a HashMap here avoid the O(n) lookup in the loop below? Is there a reason
a List was preferable — maybe insertion-order mattering somewhere I'm not seeing?"
The SAME underlying technical observation lands very differently depending on phrasing. A directive statement ("this should be X") implies the reviewer has already concluded there's no valid reason for the current approach — often true, but not always, and phrasing it as a closed directive forecloses the conversation before the author can explain context the reviewer might be missing. Phrasing as a QUESTION or an explicit TRADE-OFF ("X would give you Y, at the cost of Z — worth it here?") does two things simultaneously: it still makes the technical point clearly, AND it leaves room for the author to have a legitimate reason the reviewer doesn't yet know — turning a one-way correction into an actual two-way conversation.
"This has a null pointer risk if `user` is absent — needs a null check." ← correctness
"I'd personally extract this into a helper method, but it's fine as is." ← preference, explicitly labeled
A reviewer who doesn't explicitly distinguish these two categories forces the author to guess which comments are BLOCKING (must be addressed before merge) and which are optional taste. Explicitly labeling preference-level comments as such ("nit:", "personal preference, feel free to ignore", or similar) respects the author's own judgment on genuinely subjective calls, while still sharing the opinion — and it means the comments that ARE flagged as correctness issues carry real, unambiguous weight, rather than getting lost among a pile of undifferentiated feedback.
Review comments that exist ONLY to flag problems create a subtly demoralizing pattern over time — every review interaction becomes purely corrective, with nothing to actually reinforce what the author did WELL. Explicitly calling out a good decision in a review comment ("nice use of the Strategy pattern here — this'll make adding a new channel type trivial later") does real work: it reinforces the specific good judgment the author showed (making them more likely to repeat it deliberately, not just accidentally), and it makes the review feel like a genuine collaborative evaluation rather than a one-sided audit.
Written feedback strips out tone, pacing, and facial expression — a comment that reads as perfectly reasonable when the writer typed it can land as curt or harsh to the reader, especially on anything involving a real disagreement or a significant rework request. A quick, direct follow-up (a short call, or even just a Slack message: "hey, wanted to make sure my comment on the auth logic didn't come across too blunt — happy to talk through it if useful") is a small, low-cost habit that prevents written feedback's inherent ambiguity from quietly damaging a working relationship over time, particularly with someone earlier in their career who may be more likely to internalize sharp-sounding text feedback personally.
Q: Doesn't phrasing everything as a question slow down review and create unnecessary back-and-forth for genuinely clear-cut issues? A: For unambiguous correctness issues (a genuine bug, a security gap), a direct statement is appropriate and the question-framing isn't necessary — the technique specifically matters for judgment calls and design decisions where reasonable people could differ, not as a universal rule applied to every single comment regardless of certainty.
Q: How do you handle a case where you're confident feedback is correctness-level, but the author disagrees? A: Ask them to walk through their reasoning explicitly rather than repeating the same point more forcefully — often this either surfaces context that changes your assessment, or reveals the disagreement is genuinely about a trade-off (Payment — Requirements' correctness-over-speed framing, applied generally) worth discussing synchronously rather than resolving via more review-comment back-and-forth.
Q: Is praising good decisions in every review necessary, even for small PRs? A: Not mechanically in every single review — forced, generic praise on every PR loses its value quickly; it matters most when there's a genuinely notable good decision worth reinforcing, which won't be every PR, and forcing it where there's nothing specific to point to can read as insincere.
Q: How does this connect to Mentor a Junior or New Joiner's coaching approach? A: Directly — the question-based, trade-off-framed feedback style described here is the SAME underlying skill as Mentor a Junior or New Joiner's 'ask what they've tried' and Unblock, Don't Solve's Socratic questioning; giving good review feedback and mentoring well both rest on the same core habit of guiding someone toward understanding rather than simply handing them the answer or the correction.