Running code review across a nine hour time difference

A nine-hour time difference does not slow code review down. A review request written for a reader in the same room does. The gap is usually in the description.

The change that waited sixteen hours

Marco in Lisbon opened a four-hundred-line change on a Monday afternoon. He went to bed expecting comments by morning. The change touched the checkout path.

Wei in Taipei read it at nine the next morning. The description said fixes checkout. He closed the tab and did something else with a clear conscience.

The change sat for another day. Then it got a review that addressed formatting and missed the concurrency bug entirely. That review took eleven minutes.

Why the review arrived too late to matter

By the time comments landed, Marco had started the next piece of work. He built it on top of the unreviewed branch. That is the normal sequence.

The real cost of a slow review is not one delayed change. It is unverified work stacking behind it. Nobody counts that stack until it breaks.

Sixteen hours of waiting is not idle time. It is time in which the author builds on ground nobody has checked. The debt compounds quietly.

Batching reviews into one window

The team moved to a fixed review window. The last ninety minutes of each person’s day, with no reviews outside it. The rule was enforced for a month.

Marco’s afternoon became Wei’s morning. A change opened at four in Lisbon met comments at nine in Taipei. The wait stayed long; the variance collapsed.

Batching looks slower than responding immediately. It produces a shorter queue because context switching stops. The queue was the thing they actually cared about.

Writing the description for a sleeping reader

The new template asked three questions. What breaks today, what changes after this merges, and what was tried and rejected. Each answer took one sentence.

Those three answers replace the conversation that would have happened across a desk. That conversation takes ten minutes and is never written down. Here it has to be.

Wei stopped closing tabs. The description gave him a reason to care before he read a line of diff. The diff itself got shorter as a result.

Small changes as a timezone strategy

They capped changes at about two hundred lines, split by concern rather than by file. That doubled the number of reviews. It halved the time each one took.

Two hundred lines can be reviewed in twenty minutes with real attention. Four hundred cannot, at any hour. Attention is the binding constraint, not the timezone.

The cap did more for latency than any scheduling tool. A small change is reviewable in one sitting. A large one is reviewable across three, which means never.

What a review comment must contain

A comment that says this is wrong costs a full round trip. Here a round trip means a day. Nobody writes many comments like that twice.

Comments now state the problem, the reason, and one suggested direction. The author can act without asking back. That turned three exchanges into one.

Round trips are the unit of cost in asynchronous review, not comments. Fewer, fuller comments are cheaper. Verbose is not the same as expensive.

The overlap hour and what it is for

Lisbon and Taipei overlap for about one hour, late in the Lisbon evening. The team protected it for exactly one purpose. It has stayed protected for a year.

That hour is for disagreements that text has already failed to settle. It is not for status updates or for reading code together. Both of those are written.

Keeping the purpose narrow keeps the hour short. It also stops it from becoming a daily meeting. The moment it becomes a meeting, it stops being optional.

Approving without meeting

Approval needs a definition, or it becomes a social act. Theirs was one sentence. I have read this and I would ship it.

Wei could approve a change he did not fully understand. The condition was that the author had answered the three description questions. That condition did most of the work.

That is a lower bar than certainty and a higher one than silence. It is the only bar that works across nine hours. Certainty would block everything indefinitely.

When waiting is actually parallel work

The waiting is wasted only if the author has nothing else to do. Marco started keeping a second task for review gaps. He called it the gap task.

That task is deliberately small: a test, a documentation fix, something abandonable in ten minutes. Leaving it unfinished costs nothing. Starting it late costs nothing either.

Filling the gap is not about hustling. It is about not starting the next large change on unverified ground. The distinction matters for anyone tempted to optimise.

The measurement that changed behaviour

They tracked one number for six weeks. Hours from open to first substantive comment, which fell from sixteen to seven. Nobody changed their working hours.

The number that did not move was total review time. It stayed near sixty minutes per change. The work did not get cheaper, only earlier in the day.

Latency improved because the queue got shorter. Nobody reviewed any faster. That is the difference between a scheduling fix and a discipline fix.

What the team gave up

Immediate answers disappeared. A question asked at four in the afternoon waited until the next morning. That happened every single day for eleven months.

They accepted it in exchange for a review queue that clears daily. The queue had cleared weekly before. Nobody missed the weekly version.

The trade only works because nothing they ship is genuinely urgent. That is a fact about their product rather than a virtue of their process. A payments team could not do this.

The review that still needed a call

One change, a database migration touching billing, went through four rounds of text. It got worse with each round. Round four was longer than round one.

They spent thirty minutes on a call and settled it. That was the correct use of the overlap hour. Nobody proposed banning text afterwards.

The lesson was not that text fails. It was that text fails predictably on changes with irreversible consequences. Those get a call first, not fourth.

If your review queue cleared once a day instead of once an hour, what would actually break, and would anyone outside the team notice?