Mob Programming

The structure extends pair programming. One person drives — keyboard only, typing what the group decides. Everyone else navigates. The driver rotates on a short timer, commonly five to fifteen minutes, so nobody settles into either passivity or control. A strict version, strong-style mobbing, adds the rule that for an idea to reach the computer it must go through someone else's hands: the person with the idea navigates while somebody else types it. The rule sounds ceremonial, but it forces ideas to be spoken aloud, and spoken ideas are the ones the whole team ends up understanding.

When A Mob Beats Parallel Work

Mobbing looks wasteful by the arithmetic of typing: five people, one keyboard. It wins where typing was never the bottleneck.

Knotty problems: an incident postmortem fix, a subtle race condition, a design decision with long consequences. Five perspectives applied at once beat five sequential attempts with handoffs between them.
Knowledge spreading: after a mob session on the payment code, the whole team can maintain the payment code. There is no document to write and go stale, because the knowledge transferred while the work happened.
Convention setting: a mob writing the first repository class, the first Livewire component, or the first deployment script sets the pattern everyone else copies, with everyone present for the reasoning.

A team does not mob all day every day. The common shape is mobbing for scheduled sessions — a hard problem, an onboarding week, a new subsystem — and working solo or in pairs otherwise. If a mob session turns into one senior developer thinking while four people watch, the problem was not mob-shaped, and the session should end.

Mechanics That Keep It Working

Rotation on a visible timer is non-negotiable; the moment rotation becomes optional, the strongest personality becomes the permanent driver. Breaks on a schedule matter for the same reason they matter in pairing, multiplied by the number of people. Remote mobs work fine with screen sharing and a shared branch — the driver pushes at rotation, the next driver pulls — or with IDE collaboration tools that pass a live cursor around.

Decisions leave the session as code plus a short note. A mob that cannot say afterward what it decided and why has produced keystrokes, not shared understanding.

What To Check

Before moving on, make sure you can:

describe mob roles: one rotating driver, everyone else navigating
explain strong-style mobbing and what the "through someone else's hands" rule forces
name the situations where mobbing beats parallel solo work, and why typing speed is irrelevant to them
explain why timed rotation and scheduled breaks are structural, not optional
say when a mob session should end early

What You Should Be Able To Do

After this lesson, you should be able to propose a mob session for the right kind of problem, set up its mechanics — timer, rotation order, breaks, and a way to capture decisions — and recognize during the session whether it is producing shared understanding or spectatorship.

Practice

Practice: Design A First Mob Session

Show solution

The problem is well chosen — a pattern-setting piece of code everyone will later copy is exactly mob-shaped, because the reasoning matters as much as the code.

Mechanics: one screen, one keyboard, a visible ten-minute rotation timer, and a fixed driver order so nobody negotiates turns. Strong-style from the start: whoever has the idea navigates while someone else types it, which forces design reasoning to be spoken. Ten minutes of break per hour, and a hard stop after three hours — first mobs that run all day end with four spectators.

The driver types only what the mob decides. If the mob goes silent while one person thinks for ten minutes, name it: either the problem has stopped being mob-shaped and the session should end with an owner assigned, or the timer rotates and thinking resumes aloud.

The session must leave three artifacts: the working receiver with its tests, a short decision note (why signatures are verified before parsing, why the handler is idempotent), and the answer to "would we mob again, and on what?" The code proves the session produced software; the note proves it produced shared understanding, which is the half a mob is actually for.

Practice: Diagnose A Dead Mob

Task

Diagnose the failure and give a decision rule for fix versus stop.

Show solution

Fix the mob only where the problem deserves one. Restore the timer and fixed driver order, add strong-style so the architect's ideas must pass through other hands, and let anyone call "this has stopped being a mob" to end a session early without blame.

The decision rule: mob when the work is novel, risky, or pattern-setting, and when at least three people will need to maintain the result. Otherwise assign an owner, pair if it is risky, and give the afternoon back. Phone-checking is not a discipline problem to manage; it is accurate feedback that the session does not need five brains.

Practice: Define Mob Session Checks

Write the checklist a team runs at the end of each mob session to judge whether the session was worth five people's time, with each item observable during or after the session.

Show solution

Everyone drove. The rotation log (or commit co-authors) shows every participant typed; a session one person dominated was a demonstration.
Ideas crossed hands. Design decisions were spoken and typed by someone other than their originator, which is the observable form of shared understanding.
A decision note exists naming what was decided and why, short enough that it was actually written before people dispersed.
The problem still fit at the end. If the last hour was one person thinking while others watched, the mob outlived the mob-shaped part of the problem.
Anyone absent could be caught up by any participant, not only by the strongest one. Pick a random member and ask them to summarize; if they cannot, knowledge did not spread.
The team answered "would we mob on this kind of problem again?" and recorded the answer, so session selection improves over time.