When studies show pair programming is less efficient than individual programming for senior developers, and a wash for intermediate developers, I have to assume this is a crutch for a room full of junior/poorly-skilled developers who are helping each other get work done.

Put me with a junior developer to just "pair program" and I'll be doing all the work. I've done this before as a training exercise; I think in about 12-16 sessions, each from 2 to 4 hours, the person I was paired with made one suggestion. And I still wasn't 100% efficient because I stopped a lot to explain what I was doing.

Put me in a mob programming environment with junior developers and it will be spectator programming, or I'll be wasting time "navigating" for a junior developer and cutting my productivity by 80%. I can't help but think that even teaching could be done better than that. (For reference, the person I paired with above insisted that it was extremely helpful and educational, even though it seemed hard for me to believe.)

Can you cite the studies of which you are referring? I had not heard that the efficacy of pair programming is correlated with member seniority prior to this comment.

Sorry, last time I looked for references I couldn't find them. But I did read of at least one study to that effect. To me it seems like proving the sky was blue, though.

Remember, to be efficient, pair programming has to produce more correct code than two developers would have done programming individually. Mob programming would need to produce 5x the correct output of 5 developers. It just seems insanely unlikely that me and another developer pairing could be more than 2x as efficient as me on my own. I just don't miss that many things or get stuck almost ever.

People come to me for design advice, so I don't think having someone there to work with me on the design side would be useful either; I don't spend a lot of time flailing, I just write out really solid code, really quickly. Aside from that: I am fully in support of design meetings to sketch out architecture.

Today in ~6 hours of programming so far I would have saved about 4 minutes tracking down something that I typed wrong and that broke the tests that a second developer might (probably would) have caught. But another senior developer could have written code for 6 hours as well if they hadn't been watching over my shoulder. If we're talking about senior developers, how can you not assume they'd be able to create more code with a keyboard and no interruptions?

It really just doesn't make sense that experienced developers could possibly be more efficient if only one person is typing. Junior developers? Sure, at least that's a reasonable assumption. They have so little idea what they're doing, putting two inexperienced brains together on the problem might mean they produce more than twice as much, because they collectively know enough to work far more efficiently together.

But for experienced senior level developers? I think the burden of proof is on the advocates of pair programming. Extraordinary claims and all.

The main exception is when you have two distinct subject matter experts working together on a problem. Even then I like to have two keyboards, so it's not strictly pair programming, but collaborative/synchronized programming, with expected frequent questions and back-and-forth. I did that once recently when connecting a C/C++ low latency video and audio streaming library to Unity3d and C#; I worked with a Unity expert and while he wired up the Unity side I wired up the C++ side. I laid out what the Unity part needed to look like, and he told me how Unity interfaces to DLLs on Windows. We frequently bounced ideas back and forth but were working on different parts of the code. Worked great; had the integration working in a couple hours, plus or minus.

Ah. I understand what you were saying now.

It does seem to make sense that pairing senior engineers together would not benefit a team as much as pairing a senior with juniors.

> to be efficient, pair programming has to produce more correct code... how can you not assume they'd be able to create more code with a keyboard and no interruptions

I measure efficiency by less code not more

>I measure efficiency by less code not more

Really? So if I produce no code at all or just delete code, I'm being the most efficient, even if the goal is to add new features?

If you're going to pick on semantics, you shouldn't do it with a statement that's blatantly false on the face of it.

By "correct code" I mean code that is:

* Properly designed, refactored if necessary

* DRY

* Robust

You can't add features to "correct code" while strictly removing line count. No one is just counting lines of code here; your point is specious.

Oh, good lord, that looks awful. I'd be fidgeting around like the guy in the black shirt all day.

The worst thing is it would just be exhausting. Having to constantly deal with people for eight hours straight, with no peace and quiet or private space to think would be maddening. I'd rather swing a chainsaw bucking up firewood on a hot day.

(Author here) To be fair, we are very rarely mobbing eight hours a day. Some of us come in earlier, some leave later, and you are always free to step out of the mob and go sit for yourself (even though we have been a bit bad actually doing that). I would say that we are effectively mobbing perhaps five hours each day, and the rest is spent thinking on your own, reading up on stuff, doing your own code experiments (bringing good results back into the mob) and doing all the other stuff you need to do in a day.

Wow - that. looks. exhausting. And like an overall pretty ineffective use of engineer's time. At least for the kind of SW development that I generally do.

I can imagine certain limited scenarios where this kind of problem solving approach might be useful, but on a day-to-day basis? Nope. No way.

Thanks for a balanced perspective.

The fact that someone made a website mobprogramming.org is perhaps the biggest factor that indicts this idea as a silly fad.