An Illustrated Guide to Mob Programming

Say this is you, and you’re trying to decide what to get for lunch.

It’s pretty easy. You weigh the pros and cons — what you ate recently, what’s nearby, how hungry you’re feeling — and you make a decision.

But now, you have to decide where to go for lunch for you and your five coworkers.

Each one of them has a preference or dietary restriction that you need to take into account.

And you have to balance that with whatever restaurants you’re aware of and can recommend.

And of course, each of your friends has other opinions and context, which will affect their response to the lunch choice, that you’re not even privy to!

With all these factors at play, the most likely outcome is someone sitting at a table unhappily wondering “how the heck did we wind up here?”

One possible option is to pair on the decision — with two of you making the call for the group, it should be easier to make a tough decision, right?

With two of you, it’s easier to combine your restaurant knowledge to expose more options, and better prioritize and remove inadequate options.

But even so, there’s still four people with unknown preferences and contexts at play.

And it’s still possible (or even likely!) to wind up with someone unhappy with the result.

What to do? Is there a solution?

Well… what if everyone was responsible for making the decision together?

You may say to me: “Anne, that’s crazy. That would just devolve into looking like this.”

Or it would look like this.

Or, maybe worst of all, it would look like this.

But… just imagine with me, for a moment, what the benefits would be.

Collectively, the group could pool all their combined knowledge of great lunch spots — and also quickly rule them out when someone shares a concern.

And because everyone is sharing their context and is involved in the decision-making process, it’s highly unlikely to wind up with someone thinking “how did we wind up here?”

This leads us to the following two concrete benefits of collective decision-making.

What if we applied the same principle to writing code?

Maybe you say to me: “Anne, that’s ridiculous. That’s paying 6 people to do one person’s job.”

Maybe that’s true… if you define an engineer’s job as hands-on-keyboard code-input time.

But I think I get paid to solve problems. The written code is just a byproduct detail of that. What matters is decision-making, evaluating tradeoffs, and ideating solutions.

Another benefit of mob programming — it helps level up your less-experienced engineers into mentors.

In a pair, the more-experienced engineer tends to do the teaching.

But in a mob, that less-experienced person can turn around and be the mentor to a new person.

And they still have the experienced engineer on hand to help with tricky issues, as needed.

Maybe you say to me: “Anne, this sounds nice and all, but pure democracy can’t work in practice!”

“It will just devolve into chaos! Or autocracy!”

Luckily, much like democracy, there are techniques we can use to facilitate order.

For example, have only 1 or 2 keyboards, and rotate drivers on a timer to distribute responsibility.

I recommend you keep keyboards stationary and get people to physically move seats!

Maybe you say to me: “Anne, that sounds terrifying, especially for newer engineers. Being expected to code with your whole team watching you? Yikes!”

Luckily, there are techniques for this too.

“Backseat driving” is a technique where the mob collectively decides what to do and how, and the driver is responsible only for inputting the decisions as code.

Mobbing can be an effective way to make impactful decisions on a team.

It gives everyone a chance input, facilitates learning, and leaves no one wondering “how did the code wind up here?”

There are lots of techniques out there to help your mobbing be as successful as possible.

The best way for the group to succeed is to remember:

Be kind. Listen. And most importantly, reflect on what worked, and keep iterating on your mob techniques for the future!

Don’t be afraid to try it out!

You don’t need to mob program 100% of the time. Start by mobbing when you come to a key decision in the code.

Or, when you’re implementing a brand new pattern, and want everyone to be on the same page about it. Or when doing a big refactor, and more people’s context facilitates better decisions.