Mob Programming, and the importance of fun at work

It's been a few weeks since SoCraTes UK 2014, and I've had some time to reflect on the event and my learning experiences. Today, I want to talk about the biggest things that stood out for me.

Mind. Blown.

The session that really blew my mind was Gianfranco Alongi's explanation of Mob Programming. It takes pair programming to the next level. Its tagline is "All the brilliant people working at the same time, in the same space, at the same computer, on the same thing", and that's exactly what it is. A whole team, a keyboard, a mouse and a projector. One driver, and a few navigators, with a decent amount of rotation. I won't go into too much detail; the website linked above has much more information. This wasn't why this session blew my mind, though it was a really cool idea.

What really struck me about this session is that Gianfranco and his team have become fast friends. They care about each other, they know about each others' lives and they all respect and value each others' company.

They don't necessarily see their work as a chore. They see it as fun. One thing that Gianfranco pointed out is that work and fun are not opposites, but fun and boredom are. If you're not bored at work, it must be because you're enjoying yourself. Even if it's only a little bit.

This talk set the tone for the rest of the conference for me. I started to talk to people about their jobs, not in sessions, but over coffee or beer. We talked about why they enjoyed their jobs and what they wanted to do better. I found that most people at SoCraTes do enjoy themselves, which is not what I've found of most developers in general. I don't know why that is, exactly, though I could make a few educated guesses.

A Brief Digression

I've recently read Drive, by Daniel Pink and thoroughly enjoyed it. The central theme of the book is that financial remuneration is not the most important thing to a creative worker (and a software developer is most definitely creative). The three central drives of someone who works in a creative fashion are autonomy, mastery and purpose. What this means is that the people who derive the most fulfilment from their jobs, and therefore are enjoying themselves the most, are those who have a lot of autonomy over what they do and how they do it, can use their job to help them in the pursuit of mastery, and find a lot of purpose in what they do.

Obviously, there's a lot more to it, and the book references a large number of case studies and psychological experiments, but the introduction lays the point of the book out plain and simple, and it was obvious to me from the moment I read it that it was true. I and many of the software developers I know derive pleasure and enjoyment from our work, not because we get paid massive amounts, but because of the above three principles. We have control over our work and we do it because we find meaning in it.

And back, full circle

On the evening of the second day, Paweł Duda and I decided to work on my task list kata. I'd run a session around it earlier that day and he wanted to pair on it with me to see how it would go.

It got a bit popular, so we decided to mob, rather than pair. Six of us sat down in front of a projector, a little drunk, way after midnight, and commenced the exercise.

Cue slow progress, lots of discussion and many different ideas about the right way to go. We decided to rotate every 10 minutes (after trying 5 and deciding it was way too little). The refactoring went slowly, but it went well. We tried a bunch of different approaches and settled on one I really liked (though by then it was 2am and we opted to go to bed). Throughout, more people dropped in until we didn't just have a mob, we had a whole crew.

It looked something like this.

I found it remarkable how much enjoyed the exercise. The conversations that sprung up were really useful, and I could see the direction we were going was one none of us would have considered individually. That buzz I seek out every day at work from good conversations and solving interesting problems was there from the start, and throughout the exercise, it never left.

And then, a retrospective

Afterwards, a few of us stuck around to talk about the exercise. The conversation veered off in an interesting direction, and really brought me back to what I was looking for all along. After only an hour or so, it was fairly clear that key to mob programming seemed to be empathy for everyone else in the group, especially the driver. It was important to discuss the work, but it was also important to empower everyone to speak up and argue their case, rather than drifting into the background. When we tried to compromise, it didn't work—people were quite unhappy. And it was paramount to ensure that everyone had the same goals in their head and were working toward them.

Autonomy, mastery, and purpose.

It's not enough to make your workplace fun. Fuck those Nerf guns you see all over Silicon Valley (and some companies on this end of the planet). They're a workplace smell, just like company-mandated trips to the pub and "team-building events" (which are generally anything but). If you have to tell people they're having fun, they're not having fun.

Instead, give people some control back. Give them 20% time. If they won't take it, cut off access to the source repositories and force it on people. Give people a space to post up social activities. Give them a budget, too.

People are amazing at making things fun, just as long as you let them.