Mob Programming
A team programming approach where the whole group works together on the same code, with one person driving.
Mob Programming is a practice where an entire team works on the same thing, at the same time, on the same computer. One person (the "driver") types the code while everyone else (the "navigators") actively contributes ideas, reviews in real time, and helps steer the direction.
Participants rotate the driver role on a regular cadence, often every 10 to 15 minutes. This keeps everyone engaged and prevents one person from dominating. The rest of the team isn't passively watching. They are discussing design decisions, catching mistakes early, and building a shared understanding of the codebase.
Mob programming works well for complex tasks where knowledge sharing matters more than raw throughput. Big refactorings, bootstrapping new services, and implementing critical domain logic are good use cases. For these, the alternative is often a massive pull request that nobody can meaningfully review. With mob programming, the review happens as you go.
It does require discipline. You need a strong facilitator to keep discussions on track and prevent the session from turning into a meeting. Timeboxing is important, and you should park off-topic discussions as separate tasks. Teams that know each other well tend to get more out of it than teams with new members who may question every decision.
The common objection is that it looks like a waste of time. After all, you're putting the whole team on one task. But the hidden benefit is deep knowledge sharing that accelerates future work. Everyone knows how the code works, anyone can pick up related tasks, and there's no review bottleneck. For the right kind of work, it's faster in the long run.
The best outcome is when you use mob programming for the critical code, not trivial CRUDs or HTTP API.
References
- Combining DDD, CQRS, and Clean Architecture in Go — Recommends Pair or Mob programming as the best approach for complex refactorings. Discusses how the knowledge sharing and instant review save time in the long run, and lists questions to help decide if a project is complex enough to warrant it.
- How to Create PRs That Get Merged The Same Day — Covers mob programming as a tactic for handling big refactorings that would otherwise produce unreviewable PRs. Discusses how it works, tips for running sessions (rotate drivers, use a facilitator, timebox), and how it accelerates onboarding and bootstrapping new services.
- When it's worth to write low-quality code — Recommends mob programming for hardcore refactorings where one person working alone would produce a PR nobody can review. Notes the real-time review benefit and warns about the risk of off-topic discussions and nitpicking.
