The pair is close. One test is failing, but it is failing differently now. The driver has the editor open, the navigator has a theory, and the Google Meet call has eight minutes left.
This is the moment where a scheduled pairing session usually loses its ending.
The pair keeps going because the next command might work. Then the call ends with a dirty branch, half a theory, and no clear owner. Two hours later, one developer tries to resume and spends the first 20 minutes rediscovering what the pair already knew.
A pair programming timebox should stop new coding early enough to leave a reproducible next step. If less than 15 percent of the call remains, switch from solving to handing off unless the next command is clearly the finish.
Pairing overruns are often context-loss problems.
Pair programming already has a high attention cost. Martin Fowler's article on pair programming describes the driver as closer to the tactical work and the navigator as the person who can think more strategically, parking next steps and obstacles while the driver stays in flow: https://martinfowler.com/articles/on-pair-programming.html.
That split is useful during the work. It is also useful at the end. The driver knows what just changed. The navigator can usually see what will be hard to reconstruct tomorrow.
The overrun happens when both people stay in tactical mode too long. They chase one more failing assertion, one more dependency guess, one more console log. The calendar ends while the shared context is still in their heads.
Pairing advice often focuses on role switching and breaks. Pair Programming Workshop describes switch times as predetermined intervals or logical breakpoints where driver and navigator exchange roles: https://pair-programming-workshop.github.io/docs/glossary/switch_times/. Armakuni's practical guide recommends breaks and role swaps, including a simple pattern of coding until a break or 45 minutes, then swapping roles: https://www.armakuni.com/insights/pair-programming-a-practical-guide/.
Those practices help the middle of the session. The ending needs a separate habit: turn the last part of the call into a handoff window.
Use the final 15 percent as the handoff window.
For a 60-minute pair programming call, the handoff window starts around minute 51. For a 45-minute call, it starts around minute 38. For a 30-minute call, it starts around minute 25.
Inside that window, ask one question:
Can we finish cleanly with the next command?
If yes, run it. If no, stop adding new state and write the resume point.
This rule is intentionally blunt because the end of a pairing session is when judgment gets optimistic. The failing test looks close. The error message is new. The driver is already in the file. The pair wants the satisfying ending.
The cost of chasing that feeling is often hidden. If the next command does not work, the pair may leave with:
- local changes nobody explained;
- a failing state that cannot be reproduced;
- a theory that was obvious only during the call;
- no owner for the next attempt;
- no note about what was already tried.
A clean failing test is a better ending than a messy almost-fix. The next person can run it, see the same failure, and continue from a known point.
Write a handoff card before the call ends.
The handoff card does not need to be fancy. Put it in the PR comment, ticket, team note, or wherever the work already lives.
Use this shape:
- Branch:
- Last passing command:
- Current failing command:
- What changed during the session:
- Current hypothesis:
- Next command or file to inspect:
- Owner:
- When to resume:
Example:
- Branch:
mm/pairing-handoff-example - Last passing command:
npm test -- timer-utils - Current failing command:
npm test -- reminder-scheduler - What changed: reminder offset now reads from calendar duration, but the 45-minute case fails at the boundary.
- Current hypothesis: offset rounds down before timezone conversion.
- Next command: add one test around a 45-minute event that starts at 09:30.
- Owner: navigator picks up after lunch.
- Resume: 14:00.
This card preserves the work without pretending the call reached a clean finish. It also lets the pair stop while the shared context is still fresh enough to write plainly.
ETR's pair programming toolkit emphasizes switching roles, taking breaks, and updating a partner who has been absent: https://www.etr.org/default/assets/File/projects/Pair%20Programming%20Toolkit_FINAL%207_30_19.pdf. That "update partner" idea is the same muscle at the end of a remote call. Future-you has been absent from the last eight minutes unless you leave a clear trace.
Set the timer to cue the behavior, not the guilt.
If the reminder says "time is almost up," the pair may treat it as background noise. If it says what to do, it can change the ending.
For a 60-minute Google Meet pairing call, set:
- Minute 45: "15 min left: choose finish or handoff."
- Minute 51: "9 min left: stop new coding and write resume point."
- Overtime: "Stop and record owner, command, branch."
Minute Minder is useful for this because it starts from the Google Calendar event and shows the remaining time inside Google Meet. The custom reminder can be written in developer language, so it cues the pair's actual workflow. Minute Minder can also draft an agenda from the calendar invite, which is enough to reserve a handoff window without recording or listening to the call.
Google Meet's built-in timer can help when the host starts it manually. Google's help page says hosts and co-hosts can set a timer on the web: https://support.google.com/meet/answer/16380429?hl=en-GB. For remote pairing, the bigger win is the custom reminder text. The pair does not need a moral warning about time. It needs a nudge to preserve state.
Minute Minder does not inspect the code, read your branch, or decide whether the fix is close. It helps the people in the call notice the point where continuing will make the handoff worse.
Keep role switching separate from the end rule.
Role switching keeps the session healthy. The end rule keeps the work resumable. They are related, but they do different jobs.
If you switch every 25 minutes, keep doing that. If your pair switches at logical TDD boundaries, keep doing that too. The final handoff window still applies.
At minute 51 of a 60-minute call, do not switch roles and start a new attempt unless the next step is small enough to finish cleanly. Switch the pair into documentation mode instead:
- driver explains current local state;
- navigator writes the handoff card;
- driver runs the failing command once more;
- navigator checks that the note matches the output.
That last run matters. A handoff note that says "test failing" is weak. A handoff note with the exact command and failure gives the next person a real starting point.
When extending is the right call.
Sometimes the pair should keep going. A production incident, a release-blocking bug, or a rare overlap between two people with needed context may justify extending the session.
Even then, make the extension explicit. Decide how long you are extending, who else is affected, and what the new stop condition is. "Five more minutes" is vague. "Extend 15 minutes to either get the scheduler test green or write the handoff card" is a commitment the pair can honor.
A pair programming timebox keeps unfinished work from becoming harder to resume than it needed to be. A good ending leaves the next developer with the branch, the failing command, the current theory, and enough context to move without replaying the whole call in their head.
Sources
- Martin Fowler, On Pair Programming: https://martinfowler.com/articles/on-pair-programming.html
- Pair Programming Workshop, Switch Times: https://pair-programming-workshop.github.io/docs/glossary/switch_times/
- Armakuni, Pair Programming: A Practical Guide: https://www.armakuni.com/insights/pair-programming-a-practical-guide/
- ETR, Pair Programming Toolkit: https://www.etr.org/default/assets/File/projects/Pair%20Programming%20Toolkit_FINAL%207_30_19.pdf
FAQ
How long should a pair programming session be?
Many teams use 30 to 60 minute remote pairing blocks, or longer sessions with planned breaks. The important rule is to reserve the final 15 percent for a clean handoff if the work is unfinished.
What should you write at the end of a pairing session?
Write the branch, last passing command, current failing command, what changed, current hypothesis, next command, owner, and resume time. That is enough for the work to continue without a long rediscovery pass.
Should pair programming always stop when the timer ends?
No. Extend for incidents, release blockers, or rare context windows. Make the extension explicit and still write the state before fatigue or the next meeting breaks context.
Can Minute Minder help with pair programming timeboxes?
Yes. Minute Minder can show the Google Meet timer from the calendar event and display custom reminders such as "9 min left: stop new coding and write resume point."
Top comments (0)