Chapter 7: Asking Questions vs. Issuing Commands

Why this matters

Chapter 6 covered tone broadly; this chapter goes deeper on one specific, high-leverage technique within that broader skill: the structural choice between phrasing feedback as a question versus an imperative command. This single grammatical choice has an outsized effect on how a review comment lands, on whether it invites genuine dialogue or shuts it down, and on whether the reviewer's own understanding gets tested along the way.

Why questions often outperform commands, even when the reviewer is confident

[SENIOR INSIGHT] A command ("use a Map instead of an object here") asserts the reviewer's conclusion as the answer, leaving no space for the author to explain a constraint the reviewer might not know about. A question ("would a Map work better here, given we need frequent key lookups?") asserts the same underlying technical preference, but structurally invites the author to either agree, or explain why a Map wouldn't actually work in this specific context — information the reviewer might be missing. The question format doesn't weaken the feedback; it adds a check on the reviewer's own reasoning that a command skips entirely. This matters because reviewers are not infallible — a command that turns out to be wrong (because the reviewer missed a constraint) still gets treated as an instruction to follow, while a question that turns out to have a good counter-argument opens a conversation instead of an awkward reversal.

Command: "Change this to use async/await instead of .then() chains."

Question: "Any reason this uses .then() chains instead of async/await?
We've been standardizing on async/await elsewhere in the codebase for
readability — happy to switch if there's no specific reason for this style
here."

The question version accomplishes the same goal (surfacing the standardization preference) while leaving room for a legitimate reason to exist (perhaps this file intentionally supports an older runtime that doesn't support async/await) — a possibility the command version simply doesn't leave space for.

When a command is actually the right choice

[BEGINNER] Questions aren't universally superior — for a clear, unambiguous, non-debatable issue (a security vulnerability, a bug that will definitely cause incorrect behavior, a violation of an established, non-negotiable team standard), a direct, clear statement is more appropriate than a hedged question, which can read as uncertain about something that genuinely isn't uncertain:

Overly hedged for a clear-cut issue: "Do you think this might possibly
be vulnerable to SQL injection? Just wondering, could be wrong."

Appropriately direct: "BLOCKING: This is vulnerable to SQL injection —
`user_id` is interpolated directly into the query string. Needs a
parameterized query before this can merge (see Coding Standards guide,
Chapter 10)."

[IN PRACTICE] The practical rule: use a question when there's genuine room for a reasonable alternative view or missing context on the reviewer's part; use a direct, clear statement when the issue is objectively clear-cut (a security vulnerability, an established standard violation, a definite bug). Hedging on a clear-cut issue is its own failure mode — it can make a genuinely serious problem seem like a matter of opinion, potentially leading an author to deprioritize it.

Questions as a mentorship tool, not just a diplomacy tool

[IN PRACTICE] Beyond softening feedback, genuinely open questions ("what happens if this is called with an empty list?") are frequently a more effective teaching tool than a direct statement ("this breaks on an empty list") — a question that guides someone to discover an issue themselves tends to produce deeper, more durable understanding than being told the answer directly, directly connecting back to Chapter 1's mentorship purpose of code review. This is a genuine trade-off worth being deliberate about: a direct statement is faster in the moment; a well-posed question can produce more lasting learning, at the cost of a slightly longer back-and-forth.

Common mistakes

1. Phrasing every piece of feedback as an imperative command, even when there's genuine room for the author to have a valid reason the reviewer hasn't considered — foreclosing a conversation that might reveal useful context.
2. Over-hedging a genuinely clear-cut issue (a real security vulnerability, an unambiguous bug) into an uncertain-sounding question, risking the author under-prioritizing something that's actually serious and non-negotiable.
3. Using questions purely as a diplomatic softening technique without genuine curiosity behind them — a question asked with a predetermined, non-negotiable "correct" answer already fixed in the reviewer's mind isn't really a question, and authors can often sense this insincerity, which undermines trust more than a direct command would have.
4. Not recognizing when a guiding question would teach more effectively than a direct statement, missing an opportunity to serve code review's mentorship purpose (Chapter 1) in a routine review interaction.

Checklist: choosing between questions and commands in feedback

1. Default to questions when there's genuine room for a reasonable alternative view or missing context — this both respects the author's judgment and checks the reviewer's own reasoning.
2. Use direct, clear statements for objectively clear-cut issues (security vulnerabilities, definite bugs, established non-negotiable standards) — don't hedge something that genuinely isn't uncertain.
3. Ask only genuine questions — if the answer is actually non-negotiable regardless of the author's response, phrase it as a clear statement instead of a question with a predetermined "correct" answer.
4. Consider whether a guiding question would teach more durably than a direct statement, particularly for less experienced authors, weighing this mentorship value against the extra time a back-and-forth requires.

Discussion / interview questions

1. "Why might phrasing a review comment as a question be more effective than phrasing it as a command, even when you're fairly confident about the issue?" Strong answer: A question leaves room for the author to explain a constraint or reason the reviewer might not know about, adding a check on the reviewer's own reasoning that a command skips — reviewers aren't infallible, and a wrong command still reads as an instruction, while a wrong question opens a conversation instead of an awkward reversal.

2. "When would a direct command or statement be more appropriate than a question in a review comment?" Strong answer: For objectively clear-cut issues — a genuine security vulnerability, a definite bug, a violation of an established non-negotiable standard — where hedging with an uncertain-sounding question risks making a serious issue seem like a matter of opinion.

3. "What's the risk of using questions purely as a diplomatic technique, without genuine openness to the answer?" Strong answer: If the "question" has a predetermined, non-negotiable correct answer already fixed in the reviewer's mind, it isn't a genuine question — authors can often sense this insincerity, which can undermine trust more than a straightforward, honest command would have.

4. "How can asking a guiding question during review serve a mentorship purpose beyond just being polite?" Strong answer: A well-posed question that leads someone to discover an issue themselves (e.g., "what happens if this list is empty?") tends to produce deeper, more durable understanding than simply being told the answer directly — directly serving code review's mentorship purpose (Chapter 1), at the cost of a slightly longer back-and-forth than a direct statement would require.

Chapter summary / cheat sheet

• Questions add a check on the reviewer's own reasoning that commands skip — leaving room for context the reviewer might be missing, without weakening the substance of the feedback.
• Use direct, clear statements for objectively clear-cut issues (security vulnerabilities, definite bugs, non-negotiable standards) — don't over-hedge something that isn't actually uncertain.
• Only ask genuine questions — a "question" with a predetermined, non-negotiable answer isn't really one, and authors can sense the insincerity.
• A well-posed guiding question can teach more durably than a direct statement, serving code review's mentorship purpose — a deliberate trade-off between speed and depth of learning.

---