Three days of comments, twelve minutes of screen sharing
The bug was in a client's mobile app, and it only showed up for people with bad signal. Someone would edit a record offline, the phone would reconnect, and the backend would end up with two copies of the same edit. I owned the app side. The backend was written by a developer on the client's team who worked seven hours behind me.
We spent three days on it in pull request comments. He asked for request logs, I sent request logs. He pointed out that the two requests had different idempotency keys, so as far as the server was concerned they were two different edits, which was correct behaviour. I replied that the app only ever generated one key per edit. He asked me to double-check. I double-checked the code that generated the key and it looked fine. Each round took most of a working day, because every reply landed while the other person was asleep.
On the fourth morning I suggested a call at 15:00 my time, 08:00 his, with one sentence in the invite: "Duplicate records after offline edit, we disagree about where the second key comes from." I shared my screen, put a breakpoint in the retry path, and turned the emulator's network off and on again. About twelve minutes in, he said "wait, go back", and there it was. The key wasn't stored with the queued edit at all. It was created in a network interceptor, so every retry got a brand new one. I had been checking the code that I thought generated the key, and he had been trusting my description of it.
Neither of us would have found that from logs alone, because the logs were telling the truth. What we were missing was a shared picture of the code path, and that's the thing comments are bad at building.
What we were missing was a shared picture of the code path, and that's the thing comments are bad at building.
Both modes cost something
That story makes pairing sound like magic, and it isn't. Remote pairing spends the scarcest thing a distributed team has: overlap. Two people, one clock, and a reload cost on both sides when the call ends, because neither of you goes straight back into your own work at full speed. Async pull request review is cheaper per minute and scales much better across time zones.
Neither mode is morally superior. The useful question is which one gets correct work merged with less total calendar cost, and the answer changes from one problem to the next.
My rule of thumb, and it is only that: default to async review with a clear ask, and switch to a live session when the problem is a missing shared model rather than a missing comment. The duplicate-records bug was the second kind. Most pull requests are the first.
This sits next to planning feature and review days, which is about keeping review from eating feature time. This one is about the moment review should stop being written and become a short call instead.
Four questions before you send the invite
I answer these in order. If one of them comes back yes and async can't clear it within one review cycle, I book the call.
1. Is the blocker a missing shared model? Unfamiliar legacy code, unclear domain rules, an incident with two competing hypotheses, a first integration with an API nobody on the team has used. Two people looking at the same failing path often beats three rounds of "try logging this". If the issue is naming, a missing test you can describe in a checklist, or a bug with a clean repro, stay async.
2. Have two full async rounds failed to converge? I count a review plus the author's reply as one round. After two of those on the same disagreement, a twenty-five-minute call usually costs less than rounds three and four, plus the slow build-up of irritation that written back-and-forth produces. If round one already found the path and only polish remains, stay async.
3. Is the work high blast-radius or hard to reverse? Migrations, auth, payments, data deletion, anything at a security boundary. I'd rather walk through the risky path together before merge, even if the diff looks small. The written review still holds the record afterwards. Copy changes and isolated refactors rarely need a live session for safety.
4. Is teaching the real goal? Explaining a subsystem through review comments alone is slow and patchy. A timeboxed session, forty-five minutes with one learning outcome, is often the whole point. That isn't a failure of async culture. If nobody is learning anything and the change is ordinary, though, don't pair for the feeling of togetherness.
The two-minute cost sketch
When I'm unsure, I do rough sums. They're planning estimates, not measurements, and you should swap in your own numbers.
A pairing session:
Call length: 45 minutes
People: 2
Reload after the call: about 30 minutes each, which is my guess from my own weeks
Total: roughly 2.5 person-hours
The async route on the same problem:
Reviewer reads and comments: 30 minutes
Author revises: 45 minutes
Second review: 20 minutes
A likely third round: 40 minutes
Total: roughly 2.25 person-hours, if it converges
On paper async wins, narrowly, and when it converges in one or two rounds it really does. What the sum leaves out is elapsed time. My duplicate-records bug cost maybe three person-hours of comment writing, but it took three calendar days, and for those three days the client's testers were still filing duplicate reports. Each async gap also lands on someone mid-task, and interruptions are expensive during debugging in a way the person-hours column doesn't show.
If the alternative is a nest of tiny clarification tickets, remember that five small tickets can cost more than one feature. One session that removes a whole cluster of unknowns can be the cheaper shape even when it looks expensive on the calendar.
The pairing session that should have been a paragraph
I've got the opposite story too. On another project I booked forty-five minutes with a colleague to "walk through" a pull request that restructured how settings were loaded. We spent the first ten minutes with me explaining why I'd made the change, and the remaining thirty-five with him nodding and occasionally asking where a file had moved to. At the end he approved it.
Everything I said on that call could have been four sentences in the pull request description. I booked the call because writing a clear explanation felt like more effort than talking, which is the worst reason to spend two people's time. That's the pattern I watch for now: when I want to pair, is it because the problem needs two heads, or because I haven't done the writing yet?
When written review is clearly enough
Clear acceptance criteria, and screenshots where the change is visual
A test plan and risk notes in the pull request body
A localised change that's easy to revert
A reviewer who can run or reason about it without a tour
A disagreement at the level of preference, where the team's style guide already decides
Raise the quality of async before you raise the volume of pairing. A pull request that just says "please review" forces a live conversation to invent the question.
What to write before asking for a call
Five things in the pull request give async its best chance:
The decision you want from the reviewer: approve this path, pick between two designs, confirm a risk.
The test plan and what you already ran.
Risk notes for anything with a large blast radius.
A screenshot or failing log excerpt, not "it broke".
When you're blocked until, in UTC.
If you can't fill those in, you're asking for a guided tour rather than a review. A tour may still be the right call, but name it honestly as a session to build a shared model, not "a quick review".
How I run the call itself
One-sentence agenda in the invite, with a link to the pull request or failing test and a hard stop.
Roles: one person drives, the other directs. Swap once if the point is teaching.
Timebox: twenty-five or forty-five minutes. If it's unfinished, write the next async steps before hanging up rather than drifting into the afternoon.
Leave residue: three bullets in the pull request or ticket covering what we decided, what we tried, and who owns the next commit.
Keep it out of feature blocks: batch pairing into a labelled window instead of scattering it through someone's deep work.
Camera is optional. A shared editor or terminal isn't. Small talk is fine, briefly.
Time zones decide whose evening you're spending
If the team spans regions, "let's just jump on a call" has a hidden cost: it tends to land at the worst hour for whoever already holds the context. My 15:00 and his 08:00 worked because it was fair to both of us. A 21:00 call for one side would have worked too, technically, but tired pairing produces confident wrong decisions, and I've made a few of those.
What works on teams I've been part of is one or two short overlap slots a week, labelled for pairing and hard debugging only. Outside those, async is the default even when someone is impatient. A twenty-five-minute session at a fair hour beats an hour-long one that drags someone into evening fog.
Ways pairing goes wrong
Pairing as supervision. Watching someone type ordinary code because trust is low. That's a management problem wearing an engineering costume.
Pairing as the default for everything. Full days of remote pairing are exhausting for a lot of people and quietly cut how much the team gets done in parallel. It's a tool, not an identity.
Review theatre afterwards. If the design was agreed live, don't demand a written rerun of the same debate in the comments. Check the agreed tests exist and merge.
Checking whether it's paying off
For two weeks, tag each pairing invite with the question that triggered it: shared model, stalled async, blast radius, or teaching. At the end, count how many led to a merge or a clear decision within a day. If most of them are tagged "felt quicker" with no residue and no faster merge, the team is socialising rather than clearing confusion. That's fine in its place, but schedule it as that and raise the bar for pairing back to the four questions.
Remote pairing earns its cost when it builds a picture that comments can't, like a retry interceptor that two careful people missed for three days. It wastes its cost when it stands in for writing you didn't do. Ask the four questions, keep the call short, and leave enough behind in the ticket that nobody needs a second session to remember what the first one decided.
End of this piece
Writer
PrimedEcho
Independent notes on remote work, focus, and freelance practice. About this site.