Mob Programming & Deep Work

Deep Work — the concept of blocking out prolonged sections of uninterrupted time to do work — has been making the rounds in tech circles the past few months. In late November 2021, a colleague mentioned the Hidden Brain podcast where Deep Work’s author, Cal Newport, was interviewed, and my wife and I listened to the episode while out for a long drive. We rolled through the Green Mountains of Vermont by night, with nothing but the soothing dulcet tones of Shankar Vedantam and Cal Newport discussing the pros and cons of prolonged head’s down time. I mentioned having listened to this podcast in A Year In Open Source, and shortly thereafter read the book. If we distill the concept of Deep Work down to giving oneself the opportunity to concentrate for large blocks of time, it ends up having the sort of ascetic appeal common in this line of work. Indeed, I think that if you were to take the Agile offshoot movements and examine them, they’re frequently focused on giving engineers back time.

On the other side of things, we have mob programming, which focuses on something that seems completely contradictory to the Deep Work movement — working collaboratively throughout the day while on a video call, with only one person typing at any given time. Whereas Deep Work focuses on people achieving flow state by having lots of solo time, mob programming effectively means that you’re never working alone. Some, if not all of you, will have read the blog post I wrote on the Salesforce engineering blog recently, and I’ve fielded many questions since then from interested developers and teams who want to learn the crucial secret: how do we make mob programming work? How do we get it to scale? If this is your introduction to the phrase “mob programming,” I would highly recommend using that article as your starting point prior to reading this one.

The answer? For that we’ll go back to basics, and I’ll try to show you along the way that deep work and mob programming are really just two sides of the same coin — ways to achieve flow state. We’ve covered this topic here before, particularly within The Tao Of Apex, but here I’ll also get more into my beliefs as to how happy, productive teams do work.

Deep Work In A Pandemic

To establish the relationship between deep work and mob programming, I think the first order of business involves establishing why how we work today is so much different from the way that teams worked together in the past. The tech world is increasingly embracing hybrid work as the de facto standard, and many teams (including my own) are one step further into that progression with fully remote employees. Remote work doesn’t always appeal to people, and it’s not always convenient. It can be isolating, regardless of your motivation level. Ultimately, our mental state is the capital input that companies are “plugging in”, so our output — as invidividuals and as teams — relies on our mental state being healthy.

Despite a large corpus of evidence showing how mental health professionals have been completely slammed since the beginning of the COVID pandemic, figuring out exactly why people are struggling has proven a more elusive matter. My belief — and the belief of those I work with — is that while many prefer remote work because of the personal possibilities it opens up, those same people have at times found their desire for remote work at odds with their mental health. Again — this is not to homogenize or paint a picture with broad strokes as to your own COVID experience as a developer or as a member of a technical team. Rather, this is to observe that if these things are true in general, we can anticipate that there is some crossover within our own domain.

Deep Work requires that we have huge blocks of free time during the day, devoid from meetings and other distractions, yet we know that these are exactly the conditions that produce an adverse effect in people over time. The pandemic thus can be seen as an enormous paradigm shift, causing peoples’ ideal workflow conditions to be unachievable for a variety of reasons. If we can’t focus and can’t seem to find the time to “get things done” with a totally unblocked schedule, the pressure builds. It’s my belief that we put pressure on ourselves (and imagine the pressure of expectations when something like this happens) — and if we work in a vacuum, it’s also easy to get trapped in a cycle of negativity or lukewarm thoughts: about our expertise; about our employers; about our lives. This is also the interesting flipside to what’s been termed “The Great Resignation” — while there are people who have found, in this paradigm shift, better jobs that more accurately reimburse them (or fill them with a sense of purpose towards a common goal) than their old jobs, there are also people for whom resigning without another job lined up has been the only way to confront challenges in their lives.

So — some people thrive while working alone, but even amongst those that would self-identify as introverts or “productive only when left alone,” there’ve been surprising mental and emotional challenges. What can we do about this?

How Mob Programming Can Help

Distributed workforces face two distinct challenges (in addition to the ones, like the feeling of working alone on an insurmountable problem, associated with Deep Work, above — they’re certainly not mutually exclusive categories!):

• getting on the same page about work across various communication channels (coordinating efforts such that planned & unplanned work can be effectively handled)
• fighting information siloing. If only one person can “do the work” on a given task, the pressure builds for that person to constantly be available to answer questions, fix bugs, and develop new features for “their” program

On both of these points, mob programming removes or drastically alleviates the impediments that would — in a Deep Work world — serve as distractions. Instead of a ping via instant message on the messaging platform of your choice, or an email popping up, being on a video call serves to unite team members. Distractions will always be a part of the modern working world, but by having team members there to discuss distractions with, the chaff can be separated from the wheat; we can rely on each other to decide whether a response is necessary to an instant message on a shared problem, for instance.

Likewise, my manager recently observed something quite remarkable — the positive effects of levity. We do a lot of laughing on our calls. We allow for and encourage spontaneity. We’ve settled into a rhythm of switching up the driver and navigator every 15 minutes — and when you’re not driving/navigating, there’s no need to go into a deep explanation if you need to get up, move around, do a dance, whatever. For those that experience “Zoom fatigue,” we don’t rely on cameras being on — the primary motivating factor in doing a video call to begin with is to facilitate screen sharing, after all.

Mob programming also offers up something else that might otherwise go unnoticed: extremely effective mentoring. I’ve watched with no small amount of pride as an intern of ours went from having never seen Apex before to confidently navigating in just a few weeks. We all learn from each other, as well; it doesn’t matter how much you know if you can’t communicate effectively, and so we each get the opportunity to learn about how to communicate effectively (much as we might with a course in public speaking) — our team has occasionally been tapped to give DevOps presentations to customers, and I know our constant exercise of effective communication has served us well in these presentations. Indeed, in The Road To Tech Debt Is Paved With Good Intentions, I talk about how sharing some notable learnings gleaned from my open source work is a great example of how we all can stand to learn from one another even when initial insight happens at an individual level.

Being a self-taught developer, I know first-hand how powerful hands-on mentoring can be — two straight years of pair programming put me on a slingshot trajectory in terms of learning that I would never have been able to replicate on my own. One of the best things about my previous job was the mentoring sessions I went through with two of the junior developers there, and at Salesforce that experience has continued both within the mob and privately. This isn’t something that people get for “free”, and it’s not a one-way street between more experienced members and less-experienced ones — rather, we each have our strengths and weaknesses, and it requires humility and vulnerability across the team to be able to each proverbially (and sometimes actually) raise our hands to slow things down while mobbing when further explanation is required. Those slowdowns end up being riddled with good laughs, too.

The feeling of connectedness is strong in this kind of environment. I haven’t seen Jonathan in six years, but I see him digitally every day and thus it doesn’t feel like it’s been that long; I’ve never met the other members of my team in person, but we talk about our families and bond in a way that would bely the lack of physical interaction. Our virtual office has been the scene of some amazing moments over the past year, and I know we’re just getting started. There’s a daily rhythm to mobbing that is extremely gratifying — and that rhythm replicates the Deep Work rhythm that leads to flow state. It turns out that having a schedule — be it collaborative or pugnaciously blocked off — is the real secret to hitting a groove. Plus, there’s something very special about watching people converge on an answer — you can see the learning happening.

The archetype of the “hero programmer” — and the negative things that come with that dubious appellation — has begun to tarnish, and I don’t think that it’s a coincidence this has happened even as mental professionals themselves have struggled to support others during an incredibly challenging time for all of us. The expectation that one person can know everything and be “the person” to call or message in the event of an emergency is messy for a number of reasons, not the least of which is the high chance for burnout or mental breakdown. Indeed, I left the first company and Salesforce org I developed for (six years ago) because I had become that person, and there was no end in sight.

So — mob programming helps with these things. What else does it have to offer?

An Anecdote On Widget-Making

Recently, our team was spiking on some new ground we intended to cover for an upcoming release. We maintain a suite of applications whose focus is primarily on measuring happy teams across a variety of functions, and we’ve had some new asks come up for some of the primary applications we work on. I’ll speak very generally about these things (like needing to produce new widgets!) in the context of mob programming, because I think having the choice between two different things — and learning to pick between them as a team — is the interesting part of this story.

Let’s say we were asked to develop Feature X, where X was something that could be done in a variety of ways (as is often the case in programming). We narrowed down our options to Option A and Option B:

• Option A: on paper, this was a slam dunk. It did X, and it did it well.
• Option B: the gist of this option was “roll your own” (fully custom, with perhaps an assist from a few other teams that we knew had operated in a similar space to Feature X previously)

In a traditional work model, the spikes for Option A and Option B would have been farmed out to different team members; we would have met up to compare notes and judge which option was better suited for our course of action. Even if we were to have spiked collaboratively, if this was not our norm, it would almost certainly have come with its own friction to the process that would have slowed us down and prevented us truly sharing knowledge together.

As well, there had been a heavy emphasis on making use of Option A, and we were all excited to see if it could suit our needs without having to employ a fully custom solution. My guess would be that if we had independently spiked these options (or if we were less used to working together for something like a spike), we would have gone with Option A — because it seemed so promising, and because the initial foray into it (by whomever was tasked with doing the spike) would have come back with a lot of great results.

Working as a team, though, we were able to exponentionally multiple the amount of progress we might have otherwise made with Option A in a spike, and chose to extend the spike into a gray area — we’d very quicky gotten around 90% of the functionality we needed, but over the course of several days, we came to slowly realize that the final 10% wouldn’t be possible without applying some extremely hacked on solutions. Option A just didn’t have enough gears that we could turn with our code, and this wasn’t something that would have been initially obvious if everybody hadn’t been working on the spike together. In the end, it became clear that Option B was perhaps the only way to go, and that we could positively apply some of the learnings we’d had in spiking on Option A to accelerate the progress of our Option B spike with an eye towards immediately clarifying how it would handle the final 10% we’d gotten stuck with Option A on.

This story is extremely recent; it happened last week. I hope that it goes to show two things, in particular:

1. Working collaboratively enabled us to upskill together when exploring new technologies
2. The progress that we made on our spikes was accentuated by the presence of the entire team, and crucially, the extra bits of progress we enjoyed working on the spike together was exactly why we were able to determin the validity of both options in a timely fashion

Furthermore, since everyone worked together on these spikes, we have an extremely high likelihood of delivering our next release early because the brunt of discovery was shared between team members, and we can now all mob together effectively on bringing our learnings to bear toward delivering an extremely high quality product with 100% of the features it needs in order to succeed.

But What About The Introverts?

A colleague of mine asked me how self-identified introverts perform when mob programming. While I’ve perennially tested right on the line for extrovert/introvert across varios personality tests, instead of giving you my opinion on this, I decided to do something different: mob on it. I posed the question to our team while we were mobbing. The responses ran the gamut but the gist of each was this: “in a well-structured team where trust is kept paramount, an introvert has the space they need to contribute comfortably. Keeping our turns at the wheel and navigating times short (again, we’ve found 15 minutes to be the sweet spot for our team, personally) allows for us to recharge without being draining.” We also are not purists (or perhaps extremists?) — after testing out every other Wednesday afternoon for solo time, we actually moved to doing that every Wednesday, as we found it allowed us to focus on administrative work and other tasks that were otherwise difficult to handle in a group setting.

Let’s be real — working means good days and bad days. Sometimes we can’t get our heads in the game. Sometimes we feel lousy and are otherwise distracted by things happening around us. That’s normal, though. A supportive team can help. Indeed, I’ve occasionally been amazed on what felt like a bad day to find that the mob had brought out the best in me; that I was able through the repetition of driving, navigating, and handing off on code to emerge from what might otherwise have been a day of mental fog. We frequently ask each other for help while mobbing. We don’t always know the answer. Taking away the burden of “having to know” has taught me a lot over the past year, and it’s allowed me to enter a flow state while programming more often. We have some self-identified introverts on our team, and we have a pretty good time together.

Closing Thoughts

I know I benefitted tremendously from pair programming earlier in my career — as those days receed into the past, I’m glad to have found mob programming as a means to relive the same magic from those times in a group setting. We’ve eliminated knowledge siloing and increased collective ownership on our team. Since our product owner and scrum lead also sit in on our mobbing sessions, we’ve succeeded in not only “shifting left” as far as code quality goes, we’ve also shifted left the cycle within which we get feedback. We “mob all the things,” which makes our scrum ceremonies more seamless and our communication more open. Mob programming isn’t for everyone — it requires humility, vulnerability, and a learning mindset, and for whatever reason those things can be hard to come by within technical circles. I love it for what it can do, though: from slingshotting velocity through mutual learning and shared ownership to empowering employees (myself included!) to take time off (knowing full well that anything that comes up can be handled by the mob, instead of worrying about whether or not something that comes up will fall into my bucket of responsibilities).

Here’s how we mob:

• We use a simple timer set to 15 minutes. This has been a highly effective cross-platform solution for us, as we have people developing on Macs and people developing on Windows machines
• We use mob.sh to facilitate fast handoffs between team members. We don’t always have something to hand off — sometimes a given session involves a lot of talking and a lot of experimentation, but no actual code changes. That’s perfectly fine. “Mob dot shell” helps us to do dev work locally without unnecessarily spawning dozens of CI runs associated with our incremental commits. We use mob start to create a mob version of our bugfix/feature branches, and mob next to handoff. Most of us, at this point, simply use git pull to sync mobbing changes once mobbing has begun, but once mobbing has finished on a feature, we use mob done since it’s nice syntax sugar for collapsing all of the mob commits into a single commit on our feature or bugfix branch

That’s basically it! Use the video sharing tool of your choice, and remember to have fun!

Hopefully you’ve enjoyed learning more about mob programming, how it compares to Deep Work, and why in a distributed workforce you might look to mob programming to solve some of the common problems teams face. I wrote Mocking Apex History Records to tell the story of some hard lessons learned while mobbing. Thanks for reading another article in the Joys Of Apex — till next time!