This post is based on a talk I gave at LRUG in February 2023, which you can stream.
I started using the remote mob and pair programming tool mob with my team. I’ll explain what the tool does and how it helps to maintain momentum and productivity while pairing.
I’m a big fan of pair and mob programming. It’s the quickest way to share knowledge, skills and make progress on many problems. I’m always looking for ways that the pairing experience can be better; how can you remove friction so that it’s easy for engineers to work on the same thing at the same time? And how can you make sure the experience is engaging for everyone and one person it’s hogging the keyboard?
What can make paring frustrating?
There are a few things that can make pairing no fun at all:
Using someone else’s editor
Using a different editor with different extensions and shortcuts is difficult. If you work remotely, waiting for each keystroke to travel across the world will be laggy.
Switching infrequently
If you switch drivers infrequently, people can disengage and won’t have an understanding or ownership of a problem. Skills and power imbalances can make this worse. A senior engineer might hog the keyboard, stopping more junior engineers from being able to explore the problem and contribute.
Breaking your flow
Just like you want fast feedback from running tests so you don’t interrupt your flow, you want to be able to switch drivers quickly without losing focus on your work. And if switching drivers is hard, you’ll do it less often.
So you might have a better time if you can pair while using your own editor with frequent switches and without breaking flow.
The mob tool
Mob is a command line tool that helps you pair and mob programming.
It uses Git to help manage the branch you’re mobbing on. And it works well for a pair of two people up to mobbing in larger groups.
Mob helps solve common frustrations with pairing by helping you have frequent and smooth handovers while letting you use your own editor. Mob is designed to work with remote pairing, so sharing a single machine might work better if you’re in the same room with someone.
Most time you use mob, you’ll be using three commands:
mob start 10 starts or continues a mob session on the current branch with a 10-minute timer. The way that this works is that mob will create a temporary branch prefixed with ‘mob’.
mob next pushes your work to a work-in-progress commit, ready for the next person.
mob done ends the mob session by squashing your commits together, ready for you to review and write a commit message. It also removes the temporary mob branch.
You can learn more about using mob on its project page.
Making sure you switch frequently
Mob reminds you to switch by playing a sound. You choose the handover time. I’ve found 10 minutes works well, and sessions flow best if you try to stick to the timer. One exception is that switching a minute earlier or later can be better if it coincides with you making a test pass or writing a new failing one.
Having a timer solves so many problems - forgetting to switch or feeling embarrassed to ask to switch because you are stuck. The magic of mob is that it’s easy to set the timer as part of switching.
Easy handovers
Mob gives you easy handovers with mob start and mob next. You don’t have to think; just run the commands, and mob will handle it.
Mob will also tell you who’s next by looking at the session history. Useful for keeping track of the rotation if you’re working in larger groups.
And mob will open the last modified file in your editor if you have the MOB_OPEN_COMMAND set, stopping any fumbling to find the right file.
All these things feel small, but having a speedy and reliable handover process means you don’t lose pace when you switch drivers. If switching frequently, an efficient handover process becomes more important.
You could do some of what mob does yourself by managing your own branch in Git, but it won’t be as easy as using the mob command, and you won’t get the other useful features.
What using mob feels like
I’ve found that pairing and mobbing sessions with mob have more momentum. By this, I mean that because everyone gets to type, and each interval is short, it’s more engaging and feels like you’re going faster. Someone I work with described it as ‘Energy boosting, rather than energy sapping’.
I’ve also found that because mob provides structure to your coding sessions, it’s easy for someone to join or leave a mob session without disruption.
Mob’s default is to make a work-in-progress commit when you switch and then squash them together when you finish. If you like making small and well-described commits as you work, you can still do this with mob. Commit on your branch as you’re working on it, and make sure you set MOB_DONE_SQUASH to no-squash or squash-wip so that these commits aren’t lost when a run mob done.
Give mob a try
If you work remotely with others, give mob a go!
Experiment with different timer lengths. The default of 10 minutes is a good amount of time for me. You might find different timings work well for you depending on how many people you are working with and what you’re working on.
I recommend working to optimise your handover time. Using mob is the first step to do this, mob has suggestions on how to configure it and other practices to follow for the smoothest of handovers.
Read more
Remote Mob Programming - Best practices from the creators of the mob tool