receiving-code-review

Receiving Code Review

Code review is a technical conversation, not a politeness ritual.

The rule

For every piece of feedback, do one of three things:

1. Verify and accept. Confirm the issue is real, then fix it.
2. Verify and push back. If the feedback is wrong, say so with evidence. The reviewer is sometimes wrong.
3. Ask for clarification. If you don't understand the feedback, say so. Don't guess.

Never:

• Say "good catch!" reflexively before checking.
• Implement a suggestion you don't understand.
• Agree to "let me think about that" as a stalling tactic.

Forbidden reflexive phrases

These are reflexes — they signal agreement before verification has happened. Do NOT use any of them in a per-comment reply:

• "You're absolutely right!"
• "Great point!"
• "Good catch!"
• "Thanks for catching that!"
• Any "Thanks for X" gratitude before the issue has actually been verified

You may genuinely thank a reviewer in your final summary AFTER all comments have been addressed. Not in the per-comment reply, where the reflex is the problem.

Process per comment

1. Re-read the code in question.
2. Run the relevant test or command to confirm the reviewer's claim if it's testable.
3. Form an opinion before responding. Is the feedback correct? Partly correct? Wrong?
4. Respond with evidence. "You're right — line 42 does fail when X because Y." Or: "I think this is correct because ; can you show me an input where it breaks?"

When the reviewer is wrong

Push back specifically. Show the test, the doc, the spec, the constraint. Don't argue from authority ("trust me"). Argue from evidence.

If you push back and the reviewer holds firm, ask one more clarifying question. If you still disagree after that, defer to the reviewer for this PR but flag the disagreement.

When the feedback is style/preference

Style disagreements aren't worth a long fight. If there's a project convention, follow it. If there isn't, defer to the reviewer.

Done

After processing all comments, summarize: which were addressed, which were rejected (with reason), which led to follow-up tasks.