Pair & Mob Programming — Middle Level¶

Category: Craftsmanship Disciplines — two or more people building one piece of software together, in real time, sharing one stream of work.

Prerequisite: Junior Focus: Why and When

Table of Contents¶

1. Introduction
2. Pairing Styles in Depth
3. Ping-Pong Pairing (TDD as a Pair)
4. Strong-Style Pairing
5. Mob Programming Mechanics
6. Rotation: Timing and Discipline
7. When to Pair vs. Mob vs. Solo
8. Remote Pairing & Tooling
9. Matching Pairs
10. Trade-offs
11. Common Failure Modes
12. Best Practices
13. Test Yourself
14. Summary
15. Diagrams

Introduction¶

Focus: Why and When

At the junior level, pairing is a single thing: two people, driver and navigator, swapping. At the middle level it splinters into styles, each tuned for a different goal — ping-pong for test-driven flow, strong-style for knowledge transfer, traditional for collaborative problem-solving — and it scales up into mobbing, which has its own mechanics and its own break-even math.

The recurring middle-level decision is modality selection: given this task, this pair of people, and this goal (ship fast? teach? de-risk?), should you pair, mob, or work solo — and if you pair, in which style? Choosing well is a real skill; the difference between a great pairing culture and a resented one is mostly whether people pair on the right things in the right way.

Pairing Styles in Depth¶

The "styles" are not rigid rituals; they're named defaults you reach for depending on what you're optimizing.

The two styles worth mastering deliberately are ping-pong (because it fuses with TDD) and strong-style (because it is the most effective knowledge-transfer technique we have, and it's the engine that makes mobbing work).

Ping-Pong Pairing (TDD as a Pair)¶

Ping-pong pairing is test-driven development structured as a two-player game. It uses TDD's red-green-refactor cycle as the natural rotation trigger.

The rhythm:

1. Person A writes a failing test (red) that expresses the next small requirement.
2. Person B writes the simplest production code that makes it pass (green).
3. Person B then writes the next failing test.
4. Person A makes that pass.
5. …and so on, with refactoring done together whenever the bar is green.

A: (writes failing test)   "It should reject a withdrawal larger than the balance."
B: (makes it pass)         guard clause: `if amount > balance throw`. Green.
B: (writes failing test)   "And it should reject a negative amount."
A: (makes it pass)         second guard. Green. 
A&B: (refactor on green)   "Both guards read the same way — leave them, they're clear."
A: (writes failing test)   ...

Why it's powerful: - Forced, automatic rotation. The role swap is baked into the cycle — nobody has to remember to swap. - Balanced participation. Each person both specifies (writes tests) and implements (makes them pass), so neither gets stuck as the perpetual "thinker" or perpetual "typist." - A built-in challenge loop. Writing the test for your partner gently pins down the contract; making their test pass forces you to satisfy a spec you didn't write — surfacing assumptions immediately. - It enforces small steps. You can't write a giant test, so the code grows in tiny, reviewable increments.

When it shines: any work where you'd do TDD anyway, and especially when you want to keep two people equally engaged. It's the most reliable cure for the silent, lopsided pair.

Strong-Style Pairing¶

Coined by Llewellyn Falco, the rule is a single sentence:

"For an idea to go from your head into the computer, it must go through someone else's hands."

Concretely: the navigator has the ideas; the driver has the keyboard. If you (navigating) know what to do, you may not grab the keyboard — you must talk the driver through it. The driver, even if less experienced, owns the machine for the whole turn.

This sounds backwards. The point is precisely that it inverts the natural tendency of the expert to take over. By forcing the expert to navigate and the novice to drive, it:

• Transfers knowledge at maximum bandwidth. The expert's thinking must be spoken aloud (the novice's hands won't move otherwise), so the reasoning — not just the result — enters the novice's head.
• Keeps the novice's hands and brain engaged. Driving forces them to translate intent into syntax, which is where real learning happens.
• Stops watch-the-master dead. The expert literally cannot just do it themselves.

Levels of instruction (the navigator should aim for the highest the driver can follow):

The skill of strong-style is operating at the highest level of abstraction the driver can act on, and dropping lower only when they're stuck. Staying at keystroke level is the failure mode; staying at intent level when the driver is lost is the other.

Strong-style is the engine of mobbing: a mob is essentially strong-style pairing with one driver and many navigators, because no single navigator should be reaching for the keyboard.

Mob Programming Mechanics¶

Mob (ensemble) programming runs the whole team through one task. The mechanics that make it work:

• One driver, many navigators. Exactly one person types. Everyone else navigates — discussing, deciding, looking ahead.
• Strong-style by necessity. Since the driver is often not the person with the current idea, ideas must flow verbally through the driver's hands. This is strong-style scaled up.
• A hard rotation timer. The keyboard moves on a fixed schedule (commonly 4–10 minutes). When the timer rings, the driver hands off — no exceptions, even mid-line. Tools like mobster or mob.sh automate the timer and the git handoff.
• A consistent rotation order. Everyone knows who's next, so handoffs are frictionless.
• The "navigator with the idea speaks; the mob refines." Discussion is allowed and encouraged, but the team converges and the driver implements the agreed direction.

A typical mob day has a facilitator (often rotating), explicit breaks (mobbing is intense), and a single visible screen everyone can read. The output is one carefully-considered stream of work that the entire team understands and has effectively reviewed.

Why a team would mob the whole day: for genuinely hard problems, architectural decisions, gnarly legacy code, or rapid onboarding of several people at once, having every relevant brain on the same problem eliminates handoffs, merge conflicts, blocking questions, and "I'll explain it in the PR" delays. The cost is obvious (N people on one task); the payoff is decisions made once, correctly, with no knowledge silos.

Rotation: Timing and Discipline¶

Rotation is the mechanism that keeps everyone engaged and spreads the knowledge. Get the cadence wrong and the practice degrades.

Principles:

• Shorter than feels comfortable. New mobbers always think 4 minutes is too short; in practice short rotations keep everyone alert and prevent any one person from "owning" a chunk. The discomfort fades.
• Rotate even mid-thought. Especially in mobbing — handing off mid-line forces the whole mob to keep the context in shared awareness rather than in one driver's head. If a handoff loses context, that's a signal the mob wasn't really navigating together.
• A clock, not a vibe. "We'll swap when it feels right" reliably becomes "one person drove for 50 minutes." Use a timer for anything but the most experienced pairs.
• Track the order. In a mob, a fixed rotation order removes the "who's next?" friction every cycle.

When to Pair vs. Mob vs. Solo¶

This is the central middle-level judgement. None of the three is universally best.

The honest middle-level stance: pair and mob deliberately, not dogmatically. "We pair on everything" burns people out; "we never pair" rebuilds the silos pairing exists to dissolve. Pick the mode that matches the task's risk and knowledge-spread value.

Remote Pairing & Tooling¶

Remote and hybrid teams pair and mob constantly — it just needs the right tooling, because the co-located default (lean over and point at the screen) is gone.

Remote-specific discipline:

• Latency is the enemy. A laggy screen share makes the navigator's input arrive too late to be useful. Invest in purpose-built tools, not generic video calls.
• Give the remote driver real control. Watching someone else type over a screen share is watch-the-master by another name. Both people must be able to drive (Live Share, Code With Me, or dual-control tools).
• Over-communicate intent. You lose body language and finger-pointing; compensate by narrating more and naming things explicitly ("the method below save, line 40-ish").
• Use the tools' rotation features. mob.sh handing the branch between machines makes remote mob rotation as clean as passing a physical keyboard.

Remote pairing, done with the right tools, is often better than co-located: both people are looking at the same screen at their own comfortable font size, with their own keymap, and nobody is craning their neck.

Matching Pairs¶

Who you pair with matters as much as how you pair.

Rotate partners over days/weeks. A team where the same two people always pair rebuilds a two-person silo. Rotating pairs (a "pair stair" or daily switch) spreads knowledge across the whole team — which is the entire point.

Trade-offs¶

The pattern across the table: as you add people to one stream, per-person typing throughput falls but defect rate, knowledge spread, and decision quality all rise, and coordination cost (merges, handoffs, blocking questions) falls to near zero. Whether that trade is worth it depends entirely on the task — which is why modality selection is the skill.

Common Failure Modes¶

Best Practices¶

1. Match the modality to the task — solo for trivial/exploratory, pair for important/siloed, mob for hard/team-wide.
2. Use ping-pong to balance a pair and fuse pairing with TDD.
3. Use strong-style to teach — put the novice on the keyboard, the expert on the ideas.
4. Rotate on a real timer — short for mobs (4–10 min), per-green for ping-pong, ~15–30 min for traditional pairs.
5. Rotate partners across the team so knowledge spreads everywhere, not into a new silo.
6. Invest in low-latency remote tooling and give every participant real control.
7. Schedule breaks — collaboration is more tiring than solo work.

Test Yourself¶

1. Describe the ping-pong cycle and one reason it balances participation.
2. State the strong-style rule and explain why it's effective for teaching.
3. Why are mob rotation timers so short (4–10 min), and why rotate even mid-line?
4. Give two tasks where you'd choose solo over pairing, and two where you'd mob.
5. Why is a generic video-call screen share a poor remote-pairing tool?
6. Why should you rotate partners, not just roles?

Summary¶

• Pairing has styles: traditional, ping-pong (TDD as a two-player game, auto-rotating, balancing), and strong-style (ideas go through someone else's hands — the best teaching technique).
• Mob programming = whole team, one driver, many navigators, strong-style by necessity, on a hard short timer.
• Rotation is the engine: short and clock-driven for mobs, per-green for ping-pong, looser for experienced pairs.
• Modality selection is the core skill: solo for trivial/exploratory, pair for important/siloed, mob for hard/team-wide.
• Remote pairing works well with low-latency, dual-control tooling (Live Share, Tuple, mob.sh) — and badly with generic screen share.
• Rotate partners, not just roles, or you build a new silo.

Diagrams¶

Modality decision (compact)¶

Style → goal mapping¶

← Junior · Craftsmanship Disciplines · Roadmap · Next: Senior