Developers (or perhaps managers) are always coming up with zany and new ways of doing things. It’s good fun, but mostly just that, fun. I hate hearing ad-hoc rationalizations about “team building” or “collaboration” or “synergy”. Call a spade a spade, it’s some made up technique for having a bit of fun. Some people will hate it, some will like it. Stop coating it in bullshit buzzwords. And preferably, don’t force people to play your game if they don’t want to.
Well, it does have its pros, aside from fun, which I mentioned in the article.
So while its not for everyone and nobody is forced to do it, it does help in certain scenarios.
I can see some use for the mob, but I think I'd struggle to do it all the time.
For certain fiddly things, it can help a lot to have several eyes. "Spot the bug" type issues, perhaps. Also "let's design and agree this interface" seems like a thing that might work, eg if you're all implementing the interface in separate backends on your own time. The big one is probably "let me show you how it currently works" which probably a lot of people have done as an intro to a new team.
But just generally coding as group I think could get tiresome. You'd have to think about how to navigate things socially, ie how do I get the shy person to bring their ideas if they have any, and not let the domineering one keep talking over everyone? Plus you tend to think faster than you can implement, and that impedance mismatch would need to be dealt with across people.
Finally there's the cost of it. Four devs could easily cost the company a million bucks a year. 250 days of $4000 8 hour days -> $500/hr. Seems like a lot, you'd better have some quite scalable income to make it worthwhile. It's definitely not impossible, but chances are you want to sometimes use the $500, sometimes work separately.
Also there's tools to make this a lot easier these days. VS Code lets you share itself online, that's pretty useful.
(I was part of the group described in the article)
You are absolutely right. We also don't want to work like this all the time.
As always this is a tool which is suited for specific circumstances. We found it really helpful for implementing things that need a lot of discussions or for distributing knowledge. These are instances where you need a lot of time talking with your team anyways so the mob is a combination of implementation and the separate discussion, reviews or knowledge transfers that you do regardless.
Opposed to this, the mob is absolute overkill, if you write boilerplate or uncontroversial code the whole time. Also in situation where nobody has knowledge and all members of the mob are struggling to continue it might be better to quit and choose one or two scouts to gather knowledge before continuing.
We used git-mob in my team at Typeform, and besides the script still being a bit fiddly at the time, the overall experience was quite good, especialy with a mix of new and more seasoned developers involved.
What I recommend is increasing the rotation time to 25-30 m, especially initially.
The approach I'm experimenting with now is using vscode remote (ssh) and working with a shared remote workstation (running on EC2 and GCP).
Pros:
- no need to worry about sharing the same environment (all of you work off the same workstation after all)
- less infra: no need for external CI (you can just run the build scripts on the workstation, via commit-hooks).
I don't know if this is just advertising, but I'm the main developer behind https://mobti.me/ , which is a distributed mob programming timer. I'm aware of mob.sh, and have been asked if there would be any integrations. It has always seemed like it already has a timer, so I kept saying no, and now I have more definitive proof.
Anyway, I have a few mobbing tips that I use daily (have been consistently mob programming for 2+ years every day, and my previous job was pair programming all day for 2 years, as well):
- No heroes in the mob. If the mob cannot function without a specific person, then you are not mobbing. The only exception may be when a mob is first brought together to work on a new problem where only a single person has domain knowledge, but that shouldn't be relied on beyond a sessions or two.
- Respect the timer, but be flexible to finish ideas. Strict timer adherence can sometimes kill the mood, but when someone takes over, it can also kill it. Always acknowledge if the timer is up, and if you need to finish something, ask the mob if it's okay. Don't continue if people disagree.
- Prefer high level intentions. Don't tell people "make this variable, call it foo, and use it fetch from this endpoint" if instead you can say "can you fetch this data and store it?" - people can always ask for clarification, but they should be free to figure out the problem on their own.
- Ask for corrections after your coder is done writing an idea. If someone has the right idea, but is writing the wrong code, let it play out for a moment. Maybe the code being writing is considering a problem you haven't, or at the very least, the person writing the code can explain it when it's done so the team can decide if it's good or not. Trying to throw in corrections as someone is typing is a lot of cognitive overload.
- Reflect often, and honestly. After you're done a session, see how it went. It's okay to call someone out for being too bossy, or highlight if someone isn't being heard, as long as it's done for the sake of being a better team. Maybe the timer is too long, maybe there are too many people, maybe not the right people, and all these sorts of things should be thought about as a team.
It's a useful thing to do once in a while with your team. However, like pair programming you should not obsess about doing it all the time or forcing people to do it. But it's a great tool, especially if you have a few juniors on your team. Not everybody is a natural coach and sticking everybody in a meeting where they solve stuff together tends to be a great way to nudge seniors into teaching juniors a few things. I tend to sneak in group editing sessions in my team, usually with some vague goal of looking at some feature together or figuring out some issue. I just tell one of them something like "hey can you share your screen?" and before you know it it's 3 hours later.
Basically, staring at the same code with a group of people is a great way to spread knowledge in a casual way while actually solving some issues. The issue solving is a nice bonus but it's the knowledge spreading that really counts. You pull people slightly out of their comfort zones by making them work on a topic that isn't necessarily their specialty so they learn a few new things. And they pay attention to how others work.
One surprisingly useful thing is that the way people use tools; or even which tools they prefer can provide learning points for others. Somebody will use some neat key combination or some arcane editor feature (e.g. multi selecting bits of text) and you see multiple people doing that some time later. So, this is where I disagree with the article: the last thing you want is everybody using some uniform development environment. Let people use what they want to use show what they can do with those tools. And in case they are being clumsy, somebody will tell them "why don't you just ..." and end up learning something.
And finally, they get used to solving stuff together instead of being lone wolfs. I love it when I see people spontaneously decide to hop on discord for an hour or so to solve an issue. Often all it takes is just the realization that help is a chat message away and you can just share a screen and look at stuff together and figure it out.
While I haven't got the chance to do mob programming ever since, I'm looking forward to change this in the future. It's such a great tool for mixed-experience teams (especially good for onboarding new hires or junior devs) or cross discipline teams (having a product manager in the mob really helps removing boundaries).
> When one team member works on Windows, another in WSL, and a third in a Linux VM, there are countless road blocks to get everyone to reach a point to be able to work meaningfully. Of course we switched to Docker at some point.
This seems to be an example of how mob-programming would encourage a "put a hammer to it" approach rather than something more delicate and flexible (e.g. using a meta-build system like CMake to account for platform specificity).
I'm not saying that's always a bad thing, but if this is how many/most problems end up being handled then I'm not sure I like it.
Yep, I guess the ideal situation would be a language that is portable (and ported well enough) that it runs identically on each collaborating developer's machine as a lightweight process, and yet unopinionated enough that each developer can also run their own linting and other support tools on the codebase -- combined with a shared real-time collaborative editing space (that similarly should be cross-platform, but may not need to be related in any way to the language of the code that is being edited).
Thought this was going to be about somebody who accidentally signed up for a sketchy job a recruiter offered them and then eventually found out they were working for organized crime.
Me and my team do this informally on Discord sometimes, I had no idea it had a name. Yes, this is not something you want to do too frequently, but it can be pretty awesome - especially during those "we have no idea how to implement this" times.
There is a contingent of advocates for mob programming and to a lesser extent pairing, who are just insufferable zealots. Like most programming technique evangelists, they are devoid of nuance and hammer endlessly on their single note. More often than not they have no real accomplishments to backstop their authority either.
I'll go Bartleby: I'd prefer not. The entire reason I ever got into programming is because it was a refuge from dealing with people. Working alone on a technical problem is energizing; working with other people on the same is frustrating and makes me want to do violence within an hour or two.
The amount of outright hostility I've faced professionally for suggesting mob programming was staggering.
Some developers really like to be left alone, and it's terrible for the business, but it's been an unspoken thing (or spoken, i.e. Maker Time) for so long that any attempt at disrupting the freedom triggers a substantial backlash.
This looks like a lot of fun, I hope I'll be able to implement it someday...
Why is it terrible for the business if developers are left alone?
Personally I don't mind pair, live collab, etc., but I cannot really justify it productivity-wise. I just don't get as much stuff done as when I'm alone.
I think it's easy to feel that way, but any time I've tried to measure this objectively on teams, pairing (I can't say I've ever measured mobbing) comes out ahead, even in terms of raw velocity. There's also knock on benefits down the road as IMO with pairing / mobbing there's less of a tendency to miss edge cases and so you're less likely to have bugs that need to be revisted, which is an enormous cost savings.
This is an important point - developers have a tendency to focus on our individual performance rather than the performance of the entire organization. In my experience, while individual performance goes down for some with pair/mob programming, both quality and velocity go up for the whole organization.
And it goes without saying that we developers love our freedom because it means we can work at our own pace. Often I find when I'm pairing all day I'm putting in way more focused time than when I am soloing.
Not my experience at all. All you need is one toxic/incompetent/stubborn developer to be part of your group and everything slows down to a crawl. Removing developers from a team can dramatically increase the productivity of the team.
Not my experience at all. Perhaps you simply worked with developers that were better than you? So your productivity seemed to improve because they took more of the load? No offence but it could be a possibility. In my experience, doing pair programming etc. is great fun but it most definitely slows me down. I constantly have to explain why it makes sense to do X and why individual steps work.
Even if the instant velocity of some practice is higher, the long term average velocity might not be. Which is to say, if your devs hate pair or mob programming and quit, your teams velocity is going to be greatly impacted.
If devs consistently react negatively to a practice, in itself that’s evidence to be wary of the practice.
If devs universally react negatively to a practice, sure. If some devs don't like a practice, but it's more effective, that's an argument to ensure that you're filtering for it in hiring.
Developers are not the people who know what to build, so the productivity gains of being left alone are not productivity gains that make the business more valuable.
Because every other developer in the world screeches and retreats to their lair when you so much as mention attending a single meeting, let alone the number of meetings and conversations with clients and leadership I have to keep up with what we need to build next.
Additionally, for a dev to directly learn what to build, they’d need to work two full time jobs. Most prefer to do just the one job.
Oh, I see: The fact that you can do that doesn't mean that anyone else could, it only means that you're so much better than anyone else. OK, thanks, gotcha, good to know.
It's just two separate jobs, why would anyone sign on to doing two jobs when they can specialize in one or the other, unless they're in a situation like mine, which nearly nobody is.
My point was to give my perspective from someone who would not like it, and how much I wouldn't like it.
I would definitely look for another job if forced to do this type of coding, as it would be very uncomfortable.
If it's optional that's great, but since it involves a team as its premise someone may be forced if the majority or the more influential people want it.
In that case the minority can go find a place that respects their process, but the manager should know of that potential unintended side-effect.
I've never done it but it sounds horrific to me, and also incredibly wasteful to have 5 people all just working on one bit of code. It's like you've single-threaded your team. Surely they don't do this all the time?
I would not do it all the time, but I imagine one benefit could be that the whole team is on one page, when it comes to a central complex part of the application's logic.
Everybody is invested as everybody had (probably) their say and was part of the decision. Institutional knowledge is high across the whole team.
This for the cost of single threading the team. It is a business call and might be a valuable and valid approach in some cases.
I think it is a tool. A tool with a specific problem it solves. And if you use it all the time you are the worker that only has a hammer so that every problem looks like a nail (not you personally, but generally speaking).
Being a data analyst I remember great sessions of pair and team analysis of a specific data problem. Some sucked and were unproductive but most were great if facilitated well.
> Some developers really like to be left alone, and it's terrible for the business
This is a vague generalization, so it's hard to argue against.
The truth is, to accomplish anything difficult, developers need to be left alone to work on it. Ideally for a particularly difficult problem, you put one developer on the project and just wait for results. Of course, businesses don't like that, so you're usually forced to put several developers on the project (which makes it take longer).
As a developer, I think I speak for all of us when I say that we've experienced needing to focus intently on a difficult problem, but management keeps interrupting it by demanding progress reports and giving you the "gift" of more junior developers to "help you out".
> Some developers really like to be left alone, and it's terrible for the business
The problem is sharing credit. What is the incentive for a good developer to share credit with a bad developer especially when the don't like each other?
If you do mob programming how would you know who is making contribution and who is slacking and how to rate the performance.
> The amount of outright hostility I've faced professionally for suggesting mob programming was staggering.
For a good reason. In my experience great developers don't mind helping out but they expect to be recognized which is fair.
If you're a developer who cares about taking credit for work on a team, the very next thing you should do is figure out how to stop being a developer who cares about taking credit for work on a team, and basically nothing else.
That doesn't work in the real world. In the real world, you'll encounter other people who try to take credit for a team effort. If your solution is to stop what you're doing and spend 100% of your time trying to figure out how to not care about it, you'll go homeless and starve before coming up with a realistic solution.
All it takes is one bad developer to kill the productivity of a group of developers. Especially when the bad developer is arrogant, stubborn, wants to be in control, have bad communication skills, needs everything explained in detail, easily take offence at imaginary insults etc. etc.
It massively impacts how comfortable work is, it is kind of like suggesting that everyone wear business formal attire at work. Some loves formal business attire, are comfortable with it and wonder why not everyone would love to wear it as well, it is so much cleaner and you get taken more seriously!
I've personally not faced any outright hostility. However I notice much reserve about mob programming: "we already work together so we don't need this".
But after really using the technique, most people found it great.
