Six months ago, I got accepted to a new job. I knew before my first day that the team I’d been placed in had recently adopted remote mob programming. On my first day, I was offered resources like Remote Mob Programming, which I still recommend to anyone who wants to know more about it.
This is the simplest definition of mob programming I’ve ever found:
Mob Programming involves creating the same thing, at the same time, in the same physical or virtual space.
To be honest, I wasn’t sure how well I’d adapt to it. And it did involve a bit of a learning curve, but today I’m not sure I’d ever want to go back to programming on my own.
These are the most important things I’ve learned/about mob programming in the last six months. It’s a limited experience still, but I like to think there are some pearls here that might help anyone who’s thinking of adopting it or who’s struggling to adapt to it. ✌️
1. It lowered the initial barrier into a new workplace and project
As mentioned above, my first experience with mob programming coincided with my introduction to a new workplace, team, and project. As I’m sure anyone with prior work experience can tell you, the first few days at a new job are usually nerve-wracking. It takes weeks to acclimate to a new project’s architecture, the tools and services it depends on, its structure and code style… and then you have to figure out how to get your machine and environment set up, who’s responsible for what —
Mob programming made this a faster and less painful process than it’s been for me in the past. I was invited to participate as the passive audience in the mob on my very first day. If I had any minor questions, they were answered immediately. For more complicated questions, they were addressed at the next stopping point. If some part of my environment setup wasn’t correct, I had three other environments to compare it to and three people to advise me immediately.
For me, mobbing took the pressure off of adapting to a new workplace and made it easier to get to know my colleagues. The knowledge-sharing aspect of mob programming Is For Real and cannot be overstated, but it’s not something that happens automatically.
💡 TLDR: If you’re new to the team, don’t be afraid to ask questions: knowledge-sharing is the whole point of mob programming. If you’re welcoming a new team member, be mindful: make them feel comfortable and take the time to explain as much context as you can. This initial investment of time and energy will pay off soon enough.
2. It’s fine to play around with interval times
In mob programming, the developer who assumes the role of typist rotates at certain intervals. We found that 5-minute intervals felt rushed and added too much overhead in terms of making the handover from one person to the next. In general, we prefer 10-minute intervals.
Occasionally, if we're in an especially investigative task and everyone is terribly invested, we only rotate typists at convenient stopping points, even if that means interval times of 20 or 30 minutes. This prevents us from breaking stride or losing momentum as we investigate a bug, for example. It might not work for everyone, but it's worked well for my team.
💡 TLDR: Interval times aren't set in stone. Try to pick an interval long enough that rotating typists don't generate too much overhead and short enough to prevent the mob participants’ attention from wandering.
3. It's been unproductive for research-heavy tasks
The main idea behind mob programming is that the typist controls the keyboard and the rest of the mob must use spoken language to guide the typist as they code. When at least one person in the mob has had prior experience with the task at hand and is comfortable being the guide — sometimes not only for the typist but for the whole mob — this works very well.
What happens when you're given a task no one has prior experience with? Perhaps you're integrating your app with a new service, or you're a frontend team learning backend development, or maybe you're dealing with an obscure bug none of you have seen before.
In an ideal world, the mob would be capable of coding and researching collaboratively. But that's not as simple as we initially thought. When no one has prior experience with a given task, one of two things tends to happen: a) the typist goes unguided while the rest of the mob breaks off to research individually or b) our otherwise decent communication vanishes as we start throwing suggestions left and right.
🛠 We're in an experimental phase right now. For small research tasks, we're working on applying a little more discipline in researching collaboratively. For tasks involving deeper research, we break off from the mob for a couple of hours, research individually, and then reconvene for a review of what we learned.
In a few months, I'll get back to you on how that progresses.
💡 TLDR: Consider how well your team works in the mob for tasks involving research. If they're pros at it, excellent. If not, it's fine to research individually first and then reconvene as a mob.
4. It does not magically grant the mob good communication skills
I'm currently on a team of four and we work as a mob for upwards of 6 hours a day.
We're debate-heavy and fast-paced. We assume that if you haven't spoken up, it's because you agree; if you haven't asked a question, it's because you understand. And within the mob, we're all comfortable with speaking up and asking questions. Phrases like, “Wait, can you explain that again?” and “Listen, I'm not sure this is the best decision,” are a common, everyday type of thing.
For the most part, this works for us.
But it wasn't long before we realized this kind of communication has its pitfalls, too.
See, there's that moment when no one needs to ask questions because everyone understands... except we all understand totally different things and no one is actually on the same page, we just think we are. And it takes an hour for us to realize that we're not. And then it's a headache to get everyone realigned.
It was also pointed out to me that relying on people to speak up against the tide might really discourage them from speaking, which is fair. It's natural to feel uncomfortable when you disagree with something everyone else agreed with or when you ask a question that no one else did. It creates a barrier to entry into our team, for example, if you're shy or even if you're a junior programmer who understandably has more questions than usual.
As an awkward (if outspoken) person myself, I get it.
The advice I was given is: to make communication a two-way street. To an extent, everyone should eventually be capable of speaking up when necessary. But nothing's stopping us from creating a little more opening for others to speak, especially when they're new to the team or when we're working together temporarily, or even when we know someone has less experience than we do.
🛠 We're in an experimental phase regarding this, too. The goal is to check in with one another more often to make sure we're on the same page, and to generally put more effort into ensuring we're communicating our ideas slowly and clearly enough that it both creates space for others to interject and keeps us all properly aligned.
💡 TLDR: If you're struggling with communication in your mob sessions, try asking an impartial observer for advice. Use convenient stopping points to make sure everyone is on the same page and do your best to make communication a two-way street.
5. Slack's screen drawing feature is very convenient
Trying to communicate your thoughts about certain pieces of code inevitably ends up sounding a bit like this:
“I think what we need is to iterate though the array before that first function call — no, no, the other one. Scroll up. Keep go— nope, scrolled too far. Wait, let me get the line number... one second... line thirty-two!”
— Any mob participant, roughly once an hour.
We've tried out a handful of different screen-sharing applications, including Google Meets, Zoom, and Slack. Slack is the clear winner for one reason: its screen drawing feature is superb.
This is how it works: when one person begins sharing their screen, all other participants of the call are automatically given marker-like cursors which allow us to use the screen that's being shared as a whiteboard. Everything you draw on the screen fades away a few seconds after you stop drawing.
This means that you can literally point to the correct line. Or circle the line. Or draw an arrow to it. In fact, if you're a particularly adept artist, you can literally sketch out the code alteration you want to make. Or draw a quick flow diagram to illustrate your idea.
For people who might have difficulty proposing and explaining code changes verbally, the virtual markers provide a much-appreciated second communication medium.
Slack's desktop app is, as of early 2022, a pretty big drain on processing power but it's still the app of choice for our mob sessions. As a side note: Slack currently doesn't allow screen drawing if the screen that's being shared is on a Linux machine, which might be a bummer if that's what you use.
Another big upside is that the company already uses Slack for business communication. We created a channel to host the mob sessions for our tribe, which is currently composed of three different teams. That means that when we have a question for someone on another team, for example, we can just hop over to their call real quick — much like you'd knock on a door in a real, physical space.
TLDR: If you're choosing a communication/screen-sharing tool, I recommend Slack. The screen drawing feature is generally useful enough to make up for the way it hogs processing power.
6. It's decreased the time spent on stupid bugs
This might be one of my favorite things about mobbing: when there are 3+ people staring at the same code, someone always catches the typos. Generally before the two hours of obligatory debugging hell.
Used the whole array when you really meant to use an array item? Forgot to check a variable for a null value? Forgot to add a return statement to your function? Can't remember the difference between the ?? operator and the || operator? The mob's got your back.
💡 TLDR: Mobbing made programming less frustrating by helping to avoid small but irritating bugs. Also a time-saver, but to be honest, the decrease in frustration was the greater reward.
7. It's increased the time spent debating architectural decisions
It's no secret that every developer has a different programming style. Mobbing makes that very clear: there's one person always thinking of the code's performance, another that advocates for defensive coding techniques, another that isn't satisfied until the code is easy to understand and maintain, another that has all the classic design patterns memorized and ready for use at all times.
This means that some days, we spend more time debating architectural decisions than actually coding. I don't think of this as a downside, though you might.
In my experience, mob programming ensures quality, as curated by the different strengths of everyone in the mob. For example, we apply extra effort to make our code fast when it's necessary, but sometimes it’s better to make a code simple to understand rather than fast. Sometimes it's a choice between picking the correct design pattern and realizing that applying a design pattern at this juncture is going to make our code harder to maintain, not easier.
The important part is to not let the debate paralyze the mob. Debate is good; reaching a reasonable solution at some point in the next twenty minutes is better. Preventing the debate from turning into an argument? Vital. When you get enough experience working together to ensure all these things, it makes for a pretty good balance between quality and productivity.
8. It's been a key factor in creating a blameless culture
When something goes wrong, someone always considers pointing a finger. But when you're a mob, there's no one person to point a finger at, because the mob participants take equal responsibility for all the decisions made.
It creates a feeling of camaraderie very quickly, because everyone understands why certain decisions were made, even if they turned out to be the wrong decisions in the long run. This feeling of camaraderie easily pushes down the impulse to place blame. And once that impulse is removed, all that's left is to sit down, find a solution to the problem, and apply it.
It creates a culture where blame is replaced by understanding, and then everyone gets a little less anxious about making mistakes.
9. It's made it harder for me to focus on certain tasks
Before I got started with mob programming, I had some four years of experience with the coding on my own. One of the upsides of single-person programming is that you're always in control so you've always got your attention on the code. Otherwise, nothing gets done.
With mobbing, it's easy enough to think, “Hmm, let me just check my email real quick, the rest of the mob can carry on without me for a minute.” It's true that one of the benefits of mob programming is that the mob can afford to continue working without a participant — for example, if someone on the team has a dentist appointment or gets sick or is needed to advise another team, etc.
But that's not a reason to let your attention wander, either.
I've found that taking a break every few cycles helps keep me focused. My advice is to make the break long enough for snacks, bathroom runs, and compulsive notification checking. We take a break of 10-20 minutes twice a day. I've also found it helpful to turn off my phone's notifications during the day and to dim my second screen when I'm not actively using it.
10. It's helped me a lot with pandemic anxiety
Not that I was ever a particularly extroverted person, but the social distancing imposed by the pandemic could make even the most introverted creature on Earth feel stifled. Mobbing allowed me to be in direct contact with friends — people I genuinely like and respect — for upwards of 6 hours a day.
There's time for a lot of things as your program, not just for coding. There's time for joking and laughing and swapping memes and catching up on what we did over the weekend. There's time for being baffled by that one teammate's elephant memory and that other teammate's weird party stories.
💡 TLDR: Remember to enjoy yourself. All work and no play make for a deeply depressing workplace. It's fine to waste a few minutes on gold-tier memes every now and again.
♥ ️Thank you to