I know that some people really find value in this and even enjoy it, but I can't imagine it and would never accept a role at a company that does anything close to this.
For me, so much of the value and enjoyment in programming comes from getting locked in and grinding out some feature or fix solo based on a spec or description. I also feel like programming without listening to music is way less enjoyable.
Again, no flame at all for people who work this way. It just doesn't match at all with my own sensibilities and work style to the point where it's hard for me to imagine doing it at all.
I’ve been in three teams that has done Mob Programming full-time. In one team it was for two years and a half years.
I have lots of side projects when I get home. Love sitting by myself coding, listening to music, running a video on my second monitor. I work on some hard problems, and get a lot of stuff done.
But I have never been at a workplace where the problem was that we needed someone to grind out as much code as possible.
Doing mob programming essentially means the team works on one thing at a time. It shortens the lead time for that one thing as much as possible. That allows you to gather feedback on the solution as fast as possible. Iterate as fast as possible. Which is why you feel as you are getting so much done, even though you can go a day barely typing yourself.
And you can’t do this solo. It’s rare to find one person with all the skills necessary to change our system end-to-end efficiently, and have them never be sick or slip on a banana peel.
IME the perfect size team has been between 2-4 engineers. And the rest of the team filling in with skills depending on the domain: - data science - banking - design - marketing Etc.
It’s not always comfortable. I’m somewhat of an introvert, and I feel a group of 3 is a lot easier to work in than a pair.
But you get a lot of the right things done, and fast.
There so much to be said about this way of working, upsides and downsides. Hoping to hear a lot in this post from people with experience.
We did this exclusively at a great company I worked at for years. It was pretty great actually. Never felt stressed, we just collectively knocked out one thing after another in sequence.
I find there's a ton of value in "mob debugging"- if there's a serious issue, or your backlog or support queue is piling up with issues, turning the process into a live team exercise is fantastic.
Poor test coverage? Everyone sees the value in good tests in real time. Sloppy code that got through review? Everyone learns why you should be more diligent.
Tricky problem that needs an escape hatch from your framework to do something custom, or some advanced debugging tool usage to identify, or shed light on a database race condition? The impact of seeing it live is much better lasting than just getting a summary during a stand-up or a slack message.
I've not enjoyed pair programming, nor bottlenecking N programmers on 1 computer in general, but mob debugging on something gnarly in a shared cubicle - looking over each other's shoulders and getting a second set of eyes on something strange as they "WTF" out loud - has been repeatedly useful.
This sounds like a great way to teach juniors and exhaust introverts, but it probably also causes some reversion to the mean in terms of outputs, unless your seniors are just railroading the whole thing.
Whenever I hear about this and pair programming, I can’t help but feel like my brain is completely incompatible with this way of working. Whatever mental capacity I have for writing code and for interacting with other people seem mutually exclusive. I can do one at a time well, but I can’t do them both at once well. Just having somebody sit and watch me code is a big distraction, and I’ve observed the same in others.
The largest benefit of mob programming (or software teaming or ensemble programming) is the continuous knowledge sharing. Instead of trying to figure out context during code reviews or syncs, you do it organically all the time. Developing together builds a tight team where people grow together.
Interesting concept, but they should define mob programming on the landing page instead of having to dig into links.
Wikipedia quotes Marcus Hammarberg:
> The basic concept of mob programming is simple: the entire team works as a team together on one task at the time. That is: one team – one (active) keyboard – one screen (projector of course).
https://en.m.wikipedia.org/wiki/Team_programming#Mob_program...
The website from this hn submission seems last updated 7 years ago, perhaps the term was more popular back then.
Maybe people got interested in it again alongside the rise of Agile? Look at the date of the 4th reference on Wikipedia - it's a whole lot older than 7 years ago.
Before I read this same wiki I thought that "mob" meant mobile, like programming on a phone, ha!
https://www.youtube.com/watch?v=28S4CVkYhWA - here's Woody Zuill presenting on the subject. Nowadays this practice is also known as Software Teaming, or Ensemble Programming.
We’ve had great success using mob programming as part of our interview process. Candidates - usually associate level - have a blast as well.
Can be fun sometimes. Especially if you rowdy team and debates start happening.
In some situations and particularly for helping new hires get on board mob programming can have value, but as an introvert being in a call/huddled together constantly is exhausting and not for me.
This website hasn’t been updated in a while, perhaps we should add (2018) to the title.
> Mob Programming is a fairly new concept.
I wonder what it is, even