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.
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'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?
> 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.
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.
[+] [-] jackblemming|4 years ago|reply
[+] [-] zufallsheld|4 years ago|reply
[+] [-] krainboltgreene|4 years ago|reply
[+] [-] lordnacho|4 years ago|reply
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.
[+] [-] schurzi|4 years ago|reply
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.
[+] [-] rpastuszak|4 years ago|reply
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).
PS I wrote a quick, practical overview of different pairing/mobbing patterns: https://sonnet.io/posts/snakes/
[+] [-] simonharrer|4 years ago|reply
[+] [-] mrozbarry|4 years ago|reply
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.
[+] [-] jillesvangurp|4 years ago|reply
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.
[+] [-] shimst3r|4 years ago|reply
We based the sessions roughly on the book https://pragprog.com/titles/mpmob/code-with-the-wisdom-of-th... - having some kind of system is highly recommended.
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).
[+] [-] einpoklum|4 years ago|reply
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.
[+] [-] zufallsheld|4 years ago|reply
However in this session we already spent considerable time just to make us all productive and I agreed with the solution to use Docker.
[+] [-] buscoquadnary|4 years ago|reply
Was disappointed....
[+] [-] lobstrosity420|4 years ago|reply
[+] [-] thrower123|4 years ago|reply
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.
[+] [-] TameAntelope|4 years ago|reply
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...
[+] [-] qsort|4 years ago|reply
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.
[+] [-] hunterb123|4 years ago|reply
I occasionally enjoy live streaming code when I'm in the mood, but social things are draining and I'm usually not in the mood.
My process is personal and doesn't come on demand.
[+] [-] anentropic|4 years ago|reply
[+] [-] phendrenad2|4 years ago|reply
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".
[+] [-] throwaway5486nv|4 years ago|reply
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.
[+] [-] mbrodersen|4 years ago|reply
[+] [-] Jensson|4 years ago|reply
[+] [-] zufallsheld|4 years ago|reply
But after really using the technique, most people found it great.
[+] [-] unknown|4 years ago|reply
[deleted]