Build fluency in the vocabulary of an entire team working together on the same task at the same time.
0 / 5 completed
1 / 5
At standup, a dev mentions the entire team working together on the same task, at the same time, in the same space, on one shared computer, with one person actively typing while everyone else navigates and discusses the approach together. What is this collaborative practice called?
Mob programming is exactly this: it is a practice where the entire team works together on the same task, at the same time, in the same space, on one shared computer, with one person actively typing, or "driving," while everyone else navigates and discusses the approach together in real time. A hash collision is an unrelated hash-table concept about two keys sharing a bucket. This whole-team-on-one-computer-at-once approach is exactly why mob programming spreads context and decision-making across the entire team simultaneously, rather than through just two people at a time as in pair programming.
2 / 5
During a design review, the team runs a mob-programming session to design a tricky new pricing engine, specifically because having every team member's perspective in the room at once catches edge cases and design flaws that any individual or pair working alone would likely miss. Which capability does this provide?
Mob programming here provides whole-team context and real-time catching of design flaws, since every team member's perspective is available in the same session at once, instead of any single flaw or edge case depending on one person or pair happening to notice it alone. One developer designing the pricing engine alone and then presenting it to the team afterward means a flaw can already be baked into the design before anyone else weighs in. This catch-flaws-together-in-real-time behavior is exactly why mob programming is used for particularly tricky or high-stakes design work.
3 / 5
In a code review, a dev notices a tricky new pricing engine was designed entirely by one developer working alone, with the rest of the team only seeing it for the first time after it was already implemented and merged. What does this represent?
This is a missed mob-programming opportunity, since having the whole team's perspective in the room together while designing the pricing engine would have caught edge cases and flaws before implementation instead of after it was already merged. A cache eviction policy is an unrelated concept about discarded cache entries. This designed-solo-then-shown-to-the-team-afterward pattern is exactly the kind of risk a reviewer flags once a design is tricky enough that no single person is likely to catch every edge case alone.
4 / 5
An incident report shows a pricing engine miscalculated discounts for an entire category of customers in production, because it was designed entirely by one developer working alone, and an edge case the rest of the team would likely have caught together was missed until after it shipped. What practice would prevent this?
Running a mob-programming session with the whole team for tricky, high-stakes design work like the pricing engine catches edge cases collaboratively before implementation instead of after it ships. Continuing to let one developer design tricky, high-stakes features entirely alone regardless of how often an edge case is missed until after it ships is exactly what caused the miscalculation described in this incident. This mob-programming-for-high-stakes-design approach is the standard fix once solo design is confirmed to have missed a catchable edge case.
5 / 5
During a PR review, a teammate asks why the team runs a full mob-programming session for the tricky pricing engine instead of simply having two developers pair-program on it, given that pairing already brings a second perspective into the work. What is the reasoning?
Mob programming brings every team member's perspective into the same real-time session, catching edge cases that any two people, however skilled, might both miss, while pair programming brings real value from a second perspective but still limits the catching power to whatever those two specific people happen to notice together. This is exactly why mob programming is reserved for particularly tricky or high-stakes design work, while pair programming remains the more common everyday practice for typical tasks.