An Illustrated Guide to Mob Programming

thinking face

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

with a hot-dog

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.

a group of people

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

group with food restrictions

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

map with restaurant options marked

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

group with unspoken food preferences

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!

disgusted by a plate of lobster

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?”

2 people deciding for a group

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?

map with restaurant options marked

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

group with unspoken food preferences

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

disgusted by a plate of lobster

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

What to do? Is there a solution?

whole group deciding

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

whole group talking over each other

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

whole group yelling at each other

Or it would look like this.

whole group apathetic

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

map with restaurant options marked

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.

group getting drinks together

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?”

more perspectives shared and everyone knows how we got here

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

devs in a conference room mob coding

What if we applied the same principle to writing code?

doubtful stakeholder

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

devs whiteboarding solutions collaboratively

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.

pair teaching

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.

mob 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.

claiming pure democracy does not work

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

group in chaos

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

driver rotation technique

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!

all eyes on you while coding

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

backseat driving

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.

team celebrating with drinks

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?”

kindess, reflection, listening

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!

happy mob

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.

Externally published on Medium

Notes mentioning this note