Chapter 10: Remote and Asynchronous Review Etiquette

Why this matters

Most code review today happens asynchronously, often across time zones — the author and reviewer are rarely looking at the PR at the same moment, which removes the real-time back-and-forth that makes misunderstandings quick to resolve in person. This absence of synchronous, real-time repair is exactly what makes the tone and clarity principles from Chapters 6-7 matter even more in an asynchronous context, and introduces its own specific etiquette considerations.

Why tone matters even more asynchronously

[SENIOR INSIGHT] In a synchronous conversation, a poorly-phrased comment can be immediately clarified ("sorry, that came out harsher than I meant") the moment a misunderstanding registers on someone's face. In an asynchronous review, a poorly-phrased comment sits, unclarified, for however long it takes the author to read it and however long they choose to sit with the feeling it produced before responding — and during that gap, an author working alone (possibly worried, possibly frustrated) has no immediate signal that the tone wasn't intentional. This absence of real-time repair is exactly why the specific, careful phrasing from Chapters 6-7 matters even more here than it would in an in-person or synchronous pairing session, where tone problems tend to self-correct almost immediately through visible reaction.

Batching comments instead of a slow drip

[BEGINNER] Leaving review comments one at a time, each triggering an immediate notification, forces an author working asynchronously to context-switch repeatedly throughout their day as new individual comments trickle in. Most review tools support batching comments into a single submitted review, notifying the author once with the complete set — respecting the reality that an asynchronous author is likely to look at the review once (or a few times) per day, not continuously.

Poor: leaving 12 individual comments over 3 hours, each triggering its
own notification, as you happen to notice things while reading through.

Better: reading the entire PR first, drafting all 12 comments, and
submitting them together as one batched review — the author gets ONE
notification and can process all the feedback in one focused sitting.

Being explicit about availability and response expectations

[IN PRACTICE] Without shared physical context (seeing that a colleague is in a meeting, or has left for the day), asynchronous collaborators benefit from explicitly stating availability and expected response timing, rather than leaving it to guesswork that can easily read as unresponsiveness or disinterest:

"I've left a few comments — I'm out for the rest of today, so I likely
won't see a response until tomorrow morning my time (UTC+1). Feel free
to proceed with the non-blocking suggestions in the meantime if that's
faster for you."

Over-communicating context that would be assumed in person

[SENIOR INSIGHT] In a synchronous, co-located conversation, a lot of context is conveyed through tone of voice, facial expression, and immediate follow-up questions — none of which exist in a written, asynchronous comment. This means written review comments need to over-communicate intent that would otherwise be conveyed non-verbally: explicitly stating "this is just a suggestion, not a strong opinion" or "I want to flag this but I'm genuinely unsure — what do you think?" does real work in an asynchronous context that a shrug or a raised eyebrow would have done automatically in person.

Time zone awareness in review assignment and SLAs

[BEGINNER] A review SLA (Chapter 9) needs to account for time zone differences explicitly — "within 1 business day" means something different for a reviewer eight time zones away than for one in the same office, and a team spanning multiple time zones should account for this in both SLA definitions and in how urgent reviews are escalated (e.g., explicitly tagging a reviewer who's currently in their working hours, rather than assuming the first available person will see a notification immediately).

Common mistakes

1. Assuming asynchronous review needs the same tone discipline as synchronous review, no more — the absence of real-time repair in an async context actually makes careful, unambiguous phrasing more important, not equally important.
2. Leaving comments in a slow drip over hours, forcing repeated context-switching for an author, instead of batching a complete review into one submission.
3. Assuming silence or delayed response indicates disinterest or unresponsiveness, rather than considering time zone differences and stated availability — this assumption, left unaddressed, can create unnecessary interpersonal friction on distributed teams.
4. Relying on tone or intent being "obvious" in a written comment, without the non-verbal context that would convey it in person — leading to comments being read more harshly or more authoritatively than intended.

Checklist: reviewing effectively across time zones and asynchronously

1. Read the entire PR and batch all comments into one submitted review, rather than leaving individual comments in a slow drip that forces repeated context-switching.
2. State your availability and expected response timing explicitly when leaving a review, rather than leaving the author to guess.
3. Over-communicate intent and confidence level in written comments ("just a suggestion," "genuinely unsure, what do you think?") that would otherwise be conveyed non-verbally in person.
4. Account for time zone differences explicitly in review SLAs and urgent-review escalation, rather than assuming uniform, same-timezone availability across the team.

Discussion / interview questions

1. "Why does tone matter even more in asynchronous code review than in an in-person conversation?" Strong answer: An in-person tone misstep can be immediately clarified through visible reaction and real-time follow-up; an asynchronous comment sits unclarified for however long it takes the author to read and process it, with no immediate repair mechanism — making careful, unambiguous phrasing more important, not equally important, in this context.

2. "Why might batching review comments into one submission be better than leaving them individually as you notice issues?" Strong answer: Individual comments each trigger a notification, forcing an asynchronous author to context-switch repeatedly throughout their day; batching into one submitted review respects that an async author likely checks the review once or a few times per day, letting them process the complete feedback in one focused sitting.

3. "How should a review SLA account for a team distributed across multiple time zones?" Strong answer: Define expectations (like 'within 1 business day') with explicit awareness that this means something different for reviewers in different time zones, and account for this in urgent-review escalation by tagging reviewers currently in their working hours rather than assuming uniform, immediate availability across the team.

4. "Why might written review comments need to 'over-communicate' things that would be obvious in a face-to-face conversation?" Strong answer: In-person communication conveys a lot through tone of voice and facial expression, none of which exists in a written comment — explicitly stating things like "this is just a suggestion, not a strong opinion" does work that would otherwise happen automatically and non-verbally in a synchronous, co-located conversation.

Chapter summary / cheat sheet

• Asynchronous review lacks real-time repair for tone missteps, making the careful phrasing from Chapters 6-7 even more important, not just equally important.
• Batch comments into one submitted review rather than a slow drip of individual notifications, respecting an asynchronous author's actual checking cadence.
• Explicitly state availability and response expectations, rather than leaving colleagues to guess and potentially misread silence as disinterest.
• Over-communicate intent and confidence level in writing — tone and nuance that would be conveyed non-verbally in person need to be stated explicitly in an asynchronous comment.
• Account for time zone differences explicitly in review SLAs and urgent-review escalation on distributed teams.

---