Advice to “be kind” in code review is common, well-intentioned, and not very actionable on its own — most people giving unhelpfully harsh feedback don't think of themselves as unkind in the moment, which is exactly why a general reminder to be nicer rarely changes much about how the feedback actually lands. More specific, concrete techniques tend to do more real work than a general disposition toward kindness, because they change the actual structure of what gets written, not just the reviewer's intentions while writing it. Practical wording advice is also available in Google guidance on code-review comments.

Questions versus commands

A frequently cited, genuinely effective technique is phrasing a suggestion as a question rather than a command: “what do you think about extracting this into a separate function?” invites a response and treats the author as someone capable of reasonably disagreeing, while “extract this into a separate function” reads as an instruction regardless of the reviewer's actual intended tone. The difference matters because it changes the social structure of the interaction — a question implicitly acknowledges the author might have a reason for the current approach that the reviewer doesn't yet know about, while a command implicitly assumes the reviewer's judgment should simply override the author's without further discussion. When feedback becomes a formal performance record, employee write-up form offers a structured workplace example.

This isn't purely about softening tone for its own sake — it also produces more accurate reviews, because a command-phrased comment tends to get complied with even when the author actually has a good reason for the original approach that the phrasing didn't invite them to share, while a question-phrased comment leaves room for that reason to surface before the code changes unnecessarily.

Separating the code from the person, specifically in the language used

A related, concrete technique is a small but consistent language shift: critiquing “this function” or “this approach” rather than “your function” or “why did you do this” — the first framing keeps the discussion clearly about the code as an artifact under joint discussion, while the second, even unintentionally, personalizes a technical observation into something closer to a judgment of the person who wrote it. This is a small wording change, but it's consistently cited as one of the more effective, low-cost adjustments available, precisely because it changes the literal grammar of a comment rather than relying on the reviewer successfully managing their tone through willpower alone.

Why receiving feedback well is a matching, separate skill

Feedback quality is a two-sided skill, and the receiving half is less frequently discussed but just as consequential: treating a review comment as information about the code rather than a judgment of personal competence, assuming good faith about the reviewer's intent by default, and asking a genuine clarifying question rather than becoming defensive when a comment's reasoning isn't immediately clear, all meaningfully shape how a review interaction actually goes — even a well-phrased, carefully-worded comment can land badly if it's received defensively, and a bluntly-worded one can be handled fine by someone who's practiced treating feedback as information rather than a verdict.

Concrete language choices — questions instead of commands, the code instead of the person, explicit distinction between required and optional — do more to make feedback land well than a general intention to be kind, because they change the actual structure of what gets written, not just the reviewer's mood while writing it.

Paired with the substantive review-content guide discussed elsewhere on this shelf — what a good review actually checks for — these specific phrasing techniques address the other half of what makes review genuinely useful: not just asking the right questions, but asking them in a way that actually gets a useful, undefensive answer.