You’ve heard of pair programming… what’s mob programming?
Doing it with your entire squad!
Mob programming is the practice of programming, together. My team has been mobbing for several months now, and we love it.
If the goal is to get code into review as quickly as possible, proactively removing roadblocks that could leave a developer stuck for a day or longer is significantly more efficient than waiting to react until someone is blocked. Pair programming is typically praised for the benefits of knowledge transfer and higher code quality, but don’t dismiss the productivity gains of staying unblocked because of group problem solving!
– Jayson Ryckman, an NI colleague
How does mobbing work?
Some benefits…
- Submitting multiple PRs in a single hour!
- Since your reviewers are in the mob and have contributed to the change, the review is simply a diff check. Diff looks good? If the owners are on the team, they can (or the TL can) bypass owners on everyone’s behalf (if there are owners outside the team, loop them in!)
- But if there is feedback, it’s instant! No waiting on reviewers… they are on the call with you and can help you with the fix. Talking out a solution is 100x faster than typing it out asynchronously
- Extremely fast decision making
- When you’re in a group, you have all the squad resources at hand. Decisions that you would have otherwise mulled over or waited for answers for hours or days can happen instantly. Having access to the total sum of your squad’s expertise is extremely powerful!
- Knowledge sharing
- If the mob lead is stuck on something, the whole mob can contribute with Google searches, experiments, group debugging, etc.
- In the end, you solved a difficult problem together, and everyone shared in that. Everyone learned the same things: no work items to go share, demos to make, or status to share at standups. In fact, standups sometimes disappeared when mobbing 50%+ of the time! We always knew exactly what we were all doing
- Every engineer codes differently. Learn from each other! Become a better engineer by taking the best tools and practices from others. I know my toolset has gotten bigger by watching my colleagues code
- Parallelizing without overhead
- Why groom out work items when you can do things in parallel instantaneously?
- Example: In a recent mob programming session led by a colleague on a source code migration, we found files over our 10 MB policy to port to Git. While he was making pipeline changes (as I watched), I simultaneously put together a MURAL to get answers on each of the 8 large files, looping in two others. Before my colleague was done with his one change, we had answers on what to do to all the files… we did two things in parallel without a single work item!
- Example: Someone sees tech debt during a mob and says “Hey! I’m just gonna fix that.” The mob continues, with this one person working independently on the fix. Minutes later, they share the PR link, and the mob insta-approves the PR (since its top of mind), and done
- Having fun together!
- You now have a shared experience and built camaraderie along the way
What about LiveShare?
It’s cool, but it is not our go-to tool:
- You spend a lot of time setting it up, and the connection isn’t always reliable. This may change in the future, but right now it’s a bit of a hassle
- It’s uncommon to want multiple cursors in the same code… although when you do, it’s super worth it!
- LiveShare shares code and a command line. While this covers most of what you need to mob, it’s not everything, and you will certainly find yourself wanting to share your screen anyway
- It’s much easier if everyone is focused on a single actor (the mob lead) and their screen (shared via Teams). No need to overcomplicate it
- Finally, if you’re on Teams, you can join in from ANY device. I once went to a park and joined in on a mob session from my phone. And if you’re in the office, the new Teams conference rooms won’t make LiveShare easy
What about doing it in-person?
When we’re all back in the office, you may consider mobbing at your desk or in a conference room. In fact, this is how the practice started. However…
It’s not easy to have more than 1 other person at your desk. And in a conference room, you generally have a single monitor and uncomfortable chairs. In both scenarios, there’s only one computer.
We’ve found mobbing works best when everyone is at their personally optimized workstation, screen sharing, and using every tool & resource on the task at hand. Besides, if it gets boring during a long compile, you can multi-task for a few minutes! Which is OK! This makes the mobbing less arduous.
This is crazy. How can this be efficient?
I challenge you: try it out and see for yourselves!
The fact that you can bring an entire team together on a single project, execute on it extremely quickly while having everyone being on the same page, is truly awe-inspiring.
Mobbing works especially well at the beginning of a project when you want to learn something together or share knowledge from 1 to 2 experts. After you’ve done it for a week, you will naturally find more opportunities to “spin out” and do independent work in parallel.
In fact, “spinning out” is a recommended practice…
Pro tips:
- Rotate around. If the mob lead is busy compiling, someone else can share their screen and you can mob on whatever they are doing
- Bring people in. If you are stuck for over 10 minutes, ask yourselves, “Who might know the answer to this?” Then ping them on Teams to see if they are available for a minute or two. Then add them to the call. Chances are you will get answers 100x faster than if you emailed, and those answers will be better tuned with instant feedback
- Narrate! Mobbing works extra well if the mob lead is narrating what they are doing; i.e. thinking aloud. Besides, it’s inclusive!
- Adopt a growth mindset. No question is too dumb. As a tech lead, I try to ask very basic, almost dumb questions. If you encourage a culture of question-asking, everyone will be empowered to pause the mob and learn. It helps everyone. Brian Burgin is great at this!
- Get distracted… you don’t always have to be working on the project 100% of the time! Go on a tangent, talk about video games, share a funny video… it’s OK! You’ll get the thing done anyway and it’ll be more fun this way
- Use MURAL to share notes. MURAL is great for capturing screenshots, taking down TODOs (with sticky notes), and making flowcharts
How do we get started?
- I recommend scheduling a 2-3 hour mob programming session every week in a contiguous block; say, Thursday afternoon. During standups that week, ask “Is this something we can mob around?” Find a volunteer who will want to lead a session—no prep required. Simply join the call, share your screen, and work on whatever is there.
- Don’t forget the “Meet Now” button! If you need help, ping a buddy, then start an ad hoc Teams meeting from your squad’s channel. Let people come in-and-out… it might surprise you at how effective this is!
In Q2, there were days we spent most of our time in a mob. We attribute mobbing to our ability to get so many features done in early Q2, especially work for products we didn’t even they existed before we got the feature assigned to us.
Eventually, we dropped the recurring meeting. Mobbing has become part of our ethos: we do it all the time.