Mob Programming

Also Known As

TL;DR

Explanation

In mob programming, one person (the driver) types while the rest (the mob) contribute ideas and direction. Roles rotate frequently — typically every 5-10 minutes. The entire team focuses on the highest-value work together, producing very low defect rates and exceptional knowledge sharing. Best suited for complex problems, architectural decisions, and critical code that everyone needs to understand. A full-day mob session can outperform the same number of developer-days working in isolation on the right problem.

Common Misconception

Why It Matters

Common Mistakes

• Not rotating the driver frequently enough — one person types for too long and others disengage.
• Using mob programming for simple, well-understood tasks — it is overkill for routine work.
• Not using a physical or shared remote screen — participants must all see the same thing.
• Treating mob programming as pair programming with an audience — everyone should actively contribute, not watch.

Code Examples

// Mob programming anti-pattern — driver ignores the mob:
Developer A (driver): [typing rapidly without explanation]
Rest of team: [watching silently]
// Driver implements their own solution without discussion
// Knowledge not transferred, decisions not shared
// This is just programming with spectators

// Productive mob:
Facilitator: 'Alice, you drive. We need to implement rate limiting middleware.'
Bob: 'I suggest we check Redis first before hitting the counter'
Alice (driver): [types the Redis check]
Carol: 'We should also handle the case where Redis is down gracefully'
// Rotate driver every 10 minutes
// All decisions discussed, all code understood by everyone

References

• ↗ https://mobprogramming.org/

Tags

Related Terms