I did mob programming every day for 5 months | Hacker News Reader

I did mob programming every day for 5 months

medium.com

51 pointspetercooper50 comments

Contemplating this article over my coffee just now, I realized what bothered me about this pair programming extension. There are really two divergent schools of thought in software, that only get acknowledged periodically. There are those that see software as a factory process, where developers are essentially interchangeable cogs, tasked with churning out an amount of work each day. I would submit that much of "Agile," despite being well-intentioned, falls into this camp. The alternative view is to view software development as an engineering profession, requiring specialized education and knowledge, where individuals are respected in the same way as doctors, lawyers, accountants, or other types of highly-skilled professionals. In this model, developers might come together in an exchange of ideas or information, but otherwise have personal responsibility for their own outcomes. These conflicting schools of thought would seem to be at the root of many of these discussions of methodology and practice, where for some things like pair programming and stand-up meetings are essential, and for others, untenable.

I think a good follow up, if you have the time, would be to read through the BBC article that is also on the front page about the benefits of being a loner. The two articles seem to be arguing for different sides of the same issue.

Thank you for the suggestion!

We do mob programming for my current project, once a week, for about two hours. It is most useful for new features where people can get design paralysis, we've found. The benefit of familiarity are tremendous. The mobs have a topology, though - you can't just pull someone in from the other side of the office and say "alright John let's get rollin'". On the other hand, Architects (and other technical leaders) are good mob drop-ins. They ought to be looking at my code base anyway.

It has also helped achieve coherency in design patterns, stylistic differences (which we also use tools to enforce), and testing practices.

I get the kneejerk reaction of "it's hip or buzzwordy" but this is one that has worked well for us.

Never really liked mob programming at my old job. Just made me really distracted and made me feel like I wasn't needed as in my head I knew I was working with talented developers who could do what we were doing by themselves. Basically just ended up being a human typo spotter.

One thing we found useful though was using a timer for the 'driver' (person behind the keyboard). I made a terminal one here:

https://github.com/benbristow/agile-timer

It's more designed for Mac as it uses the 'say' command but could be tweaked easily for Linux users.

Although when I started at my new job I would have found it useful. Trying to figure out custom frameworks where the documentation was in a few people's heads wasn't fun.

Another buzzword - this us simply pair programming but with 3 (or more) people? Frankly, I find working in this way to work but in an extremely inefficient manner. A simple code review is often much more insightful, more efficient, and easier to communicate versus piling around a single keyboard - just some thoughts.

I don't agree, pair/mob programming has its benefits.

In the early stage of starting a project you need to set up the structure of the application you are going to build. The architecture, and rough outline of where what needs to go.

By using mob programming we've been able to get an entire team ready to go at full speed in no time. Everyone knew the thought behind every decision made, and everyone had enough knowledge of the structure to hit the ground running.

That is way better than having the lead dev or architect do that work on his own and then having to spend time to explain it all to the rest of the team.

Mob programming has its advantages, but I wouldn't want to use it too often.

So what's the difference between that and gathering around a whiteboard and doing some design/planning work?

The difference is it has a name, so consulting and training can be sold and conference talks can be made.

To me personally; not much.

The main difference is walking out of the room with a pull-request setting up the structure in code instead of walking out the room with a photo made of a whiteboard.

I find that starting new projects with multiple people right away is almost always a recipe for disaster, or at least drastically reduces the potential quality of the project before even writing the first line of code.

Maybe it works for small projects or teams of mostly junior developers. But for anything remotely complex I can say from experience the architecture won't be ready in a few meetings but rather after much hammock time.

That architecture will then become a main factor in your productivity, maintainability and performance. These 3 are very, very hard to optimize for once the architecture is in place.

Other than for code reviews or mentoring junior developers, I've never seen pair/mob programming works with quality results. Its nearly impossible to solve complex problems when outside the zone, and its nearly impossible to get in the zone in a pair/mob setting.

I think at least the zone part depends on personality. I have a much easier time getting in the zone when pairing and riding off each other's ideas.

That makes it sound like the whiteboard session is much better. Cause there's planning involved, instead of just throwing some code together.

>Another buzzword - this us simply pair programming but with 3 (or more) people? Frankly, I find working in this way to work but in an extremely inefficient manner.

Pair (and mob) programming makes a lot more sense when you think of it primarily as a mechanism to transfer skills and information about the project.

It's highly inefficient to have new joiners on a project getting stuck constantly. Pairing (or mobbing, if there's more than one new joiner) makes sense at least for the first two weeks.

Depends on what kind of work are you doing. Designing a DB schema or API vs styling a website.

Its like extreme programming but even MORE extreme. EXXXTREME PROGRAMMING!!! If you can get it sponsored by Red Bull maybe it can be a sport.

I'm gonna start pushing for calling it "hive programming".

Good idea. I'd never heard of mob programming before. When I clicked the article I expected an article about programming for the mob.

Yes, I was thinking about methods for creating and managing mobs. But then, I've read Burroughs.

As did I. Apparently pointing this out is grounds for downvoting, though.

Too many cooks spoil the broth. Effective teamwork does not mean we all need to work on the exact same thing at the same time. The best teams I've been on have people who are "t shaped" and have the autonomy to self organize. It's ok to collaborate but it's usually best to communicate what needs to be done, split up the responsibilities, and then complete the work independently. In my experience smaller teams output higher quality work at a faster rate. Bigger teams have less accountability and are prone to wasting time bike shedding.

All of the problems the author states are symptoms of other issues in the organization which will not be solved by this particular style of group work. Incomprehensible code is still incomprehensible regardless of whether it was written by 1 or 10 people. Everyone is bad at this to begin with, how can you expect to get better if you have someone else solve all of your problems? Going through a bit of a struggle is a good thing, as it gives you confidence that you can solve new problems as they arise.

>"T-shaped" ?

It's a phrase usually used to refer to developers who have a broad base of knowledge (the horizontal stroke of a capital "T") as well as a single area of particular specialization (the vertical stroke of the "T").

Right on. Thanks.

"Jack of ~all~ many trades, master of ~none~ a few."

Sounds like something a consultancy would insist on to juice contract value.

I see a huge opportunity to mentor Junior devs by doing this.

Completely agreed, but this is probably the only real use for this technique. For experienced (read: expensive) developers, the cost overhead of having two or three developers working on one problem (which is likely a one-person task anyway) is too great. I'm certain proponents would push the quality angle -- that two or three pairs of eyes and brains focused on the problem improves quality -- but there are other ways to boost quality while maintaining a more realistic productivity and cost structure.

For less-experienced developers though, this would be a great way of building team cohesiveness, training/mentoring, plus likely boosting productivity.

I would argue it's also useful for new team members in general, or for teams that have in the past been unorganized. At my current job I've spent a lot of time refactoring code so that there's some more unity among everything, because everybody does their own thing and doesn't really collaborate, which makes maintenance a pain in the ass. Something like this that kind of forces people to work together and create some kind of unified style could be very beneficial.

Not to mention when I've seen experience developers show something they've been working on for the past two weeks, only to be told what they've shown is a disaster because they never had any other eyes on it to question their design decisions.

I can see this for a team of interns on a summer project, but not senior devs that don’t really get stuck that often, or know to involve someone for the brief periods where they need a second set of eyes.

I work for a company that almost exclusively does mob programming. As in I'm in a mob 95% percent of the day, every day.

What I miss most is "the zone." Pretty much every single line of code requires a verbal interaction with my coworkers. I used to love the feeling of coming up for air after 2 hours of visualizing abstractions inside of my own head, kind of like that feeling of reading a novel and suddenly coming to and remembering all of the action like a movie had occurred in my imagination.

Programming used to be unbelievably fun because of that. It's still fun, but some of the magic is gone.

I've had a lot of success with paired programming in different team/project environments and really have only done 'mob' experiments. I didn't find there to be a lot of benefit to mobs vs pairing unless the goal was to make sure every team member was highly aware of what was going on in a specific commit/feature-branch.

I definitely think ad-hoc mobbing has it's place and most if not all big design/redesign work the team undertakes should be in a mob form. I'm not sure I could see it being a good practice day to day for most teams/projects though.

As a junior dev only a couple years into programming I love pair programming. I spend way less time stuck. It's been life changing for me.

I’ve just finished a 4 year PhD, working alone. Now, I’m building my company building software, but I’m currently a one man show, and again, working alone.

Do you reckon 3 people in a mob is more productive in the short term than 3 people working independently?

I wonder if 3 people who typically work independently could time-share each other to work on projects in a mob.

Unfortunately, you're probably broken at this point. Too much time spent in the productive bliss of solitary work breeds unrealistic expectations when pulled back into the conformity of collaboration. It's like shackling a thoroughbred to a plow.

If you've got VC money to burn, sticking a whole squad of expensive programmers in a room and gating their output to slightly more than a single person might be a reasonable option...

Based on the headline I expected this to be someone talking about programming for organized crime. Imagine my disappointment when it's just another bloody buzzword.

We have been doing mob programming for the last month or so. It works well, but everyone needs to be engaged. Otherwise, it's just a distraction.

I can't wait for recruiters to incorporate this to their lingos

I've never heard of "Mob Programming" before coming across this thread. It's as if somebody looked at pair programming and said "This sucks... but I think I can make it suck more."

Collaborate on architecture, interfaces, design, etc.. sure. But, as an introvert, sitting in a room amongst a mob of code monkeys screaming and flinging feces about the room whilst trying to share a single keyboard doesn't sound like the best way to build good software. I'd have a blinding headache after an hour of this sort of thing.

I am not introvert but I feel very uncomfortable doing pair programming (specially with one keyboard).

When I am driving some times I get questions about things that I don't care at the moment, why I am using vim/sublime this way, why I named the variable like that. This causes me to lose concentration. If I am "navigating" (as the article mentions) I try to not make many comments but I feel very stressed about the other person not solving the problems the way I would.

I am very open to brainstorming meetings etc, but then just let me go back to my computer in my space to write code. Then I send a PR to someone in the team for review and we can discuss about it.

However there are scenario where I think pairing is very useful, for instance when doing risky changes to infrastructure. The driver share her screen and then it tells the other people watching every action before executing, like "I am going to switch the DNS record now to X.." and the copilot answer "go ahead", "I will wait 2 minutes"..."I am taking down this load balancer.. "

I think you identified the best use of pairing: high-risk changes. Avoiding costly mistakes is easier with "another pair of eyes." Pairing on the creation of yet another DTO has very little, if any, value.

I use pairing when introducing a peer to a new concept, a new library, or helping them get complicated stuff working. I think pairing works best when it has a very intentional purpose - "Together, we're going to get this service up and running locally so you can develop against it" kind of thing.

Sure, but I would just call this 'mentoring' rather than pairing :)

T minus 1 hour until every job posting has 10 years of Mob experience required.

This is just pair programming, or "swarming".

And, I hate it, especially when told to do it, as opposed to when it happens naturally.

> Given that most programmers get in hot sweats just thinking about the idea of working with other people

Nice.

It's a dumb line, but please don't post unsubstantive comments here.

A person that struggles with CSS and performs better when two other developers are telling them what to do should probably just not be in this industry at all. This sounds like a nightmare for any competent developer.

If I have any kind of hard CSS problem, I ask someone else on the team to handle the styling. I could do it, but it would take me 3x as long and make me miserable.

No one else on the team can handle integration with federated identity systems the way I can, though. I know all the technologies and their security pitfalls that have to be coded around. No one else knows those things. Are they nightmares for competent developers and not people who should be in the industry?

both - CSS and federated identity - are basic stuff that a competent developer should be able to handle efficiently.

I think "this industry" might be a bit broader than a bunch of CSS experts or even people competent in CSS. This seems to highlight his point rather than dismiss him as a developer. He's not a CSS guy so having people there with him gets his work done faster and helps him understand.

Reply on news.ycombinator.com