A useful first answer
Give the reviewer a decision path, not a tour of every line
A reviewer usually needs four things: the problem, the design choice, the evidence, and the open question. This order explains why the change exists before implementation detail. Use one sentence for each part, and name any known limitation. That makes the explanation precise without pretending the patch is perfect.
State the problem
Describe the user or system effect in plain language. Avoid beginning with a file name or function name.
Users could submit the same payment request twice after a timeout.
Name the design choice
Say what you changed and why this option fits the current boundary.
I added an idempotency check at the request boundary because every retry passes through it.
Show relevant evidence
Mention the test, trace, or documented rule that supports the choice. Do not say only that it works.
The new test sends the same key twice and confirms that only one operation runs.
Ask for the decision
End with the exact point on which you need review, especially when two designs are possible.
Could you check whether this boundary is the right owner for the guard?
Worked conversation one
Explain the reason before defending the implementation
A reviewer asks why a new guard is needed+
You are discussing a pull request that prevents two workers from processing the same job.
Why do we need another check here? The worker already checks the job status.
The existing check happens after the job is claimed. Two workers can pass the earlier read before either claim is saved. This change makes the claim conditional, so only one worker can succeed.
What evidence do we have that the conditional claim closes that gap?
I added a concurrency test that starts two claims with the same job ID. One succeeds and one returns the existing conflict result. I also kept the later status check as a defensive check.
Please add that race explanation to the pull request summary. Then I can review the database boundary separately.
Agreed. I’ll add the sequence and point you to the conditional update and the concurrency test.
The answer uses timing, behaviour, and evidence, then ends with a reviewable next step.
Worked conversation two
Separate a blocking concern from a useful follow-up
The reviewer prefers a larger refactor+
Your patch fixes an incorrect cache key. The reviewer suggests replacing the entire cache wrapper in the same change.
Could we replace the wrapper now? That would avoid touching this code twice.
I agree that the wrapper needs simplification. For this patch, the failure comes from omitting the tenant ID from one key. The two-line fix and regression test remove that failure without changing eviction behavior.
I’m concerned that the small fix leaves the confusing API in place.
That concern is valid. Would you treat the wrapper refactor as required for this fix, or can we record it as a follow-up with its own migration tests? If it is blocking, I’d like to understand which current risk the refactor must remove.
The production bug is covered by your test, so the refactor can be a follow-up. Please link the issue here.
I’ll link it and state that this patch changes key construction only, not cache lifetime or eviction.
Acknowledge the broader concern, protect the patch’s purpose, and ask whether the suggestion blocks approval.
This is obviously the simplest solution.
I chose this option because it changes one boundary and keeps the existing retry behavior.
Your suggestion is out of scope.
The suggestion addresses maintainability. Could we separate it from this production fix and define the tests it needs?
Make it fit your review
Change the emphasis for three common situations
- For a small bug fix: lead with the failing behavior, the narrow correction, and the regression test.
- For a design change: explain the constraint, compare the serious alternatives, and ask for review of the trade-off.
- For an urgent patch: state what is known, what is intentionally deferred, and what monitoring or rollback boundary exists.
- Choose one real or fictional change and write four labels: problem, choice, evidence, review question.
- Speak for 45 seconds without naming files until after you have explained the problem.
- Ask yourself one difficult reviewer question and answer it with a fact, a boundary, and a next step.
- Repeat the explanation in 30 seconds, removing history that does not change the review decision.
Choose how to continue
Use independent voice practice for repetition, or choose teacher guidance for a broader learning plan.
Rehearse your explanation aloud
Build confidence speaking English with Flalingo: AI Speaking Coach. Try voice conversations and get feedback after you speak, then use what you learn in your next team discussion.
Explore the AI speaking coachBuild a longer-term speaking plan with a teacher
If you want planned live English lessons and teacher support for broader professional communication, review the Flalingo method.
Explore the Flalingo methodSources
- The Standard of Code Review
Google Engineering Practices · Reviewed 10 Sept 2026
Used for the distinction between technical evidence, preference, blocking quality concerns, and non-blocking polish. It describes Google’s review practice, not a universal approval rule.
- Helping others review your changes
GitHub Docs · Reviewed 10 Sept 2026
Used for clear change context: problem, approach, result, focused scope, and areas needing attention. It does not validate the fictional technical examples.