Hacker News Reader

Comment by wpietri | Hacker News Reader

This is also basically the standard critique of pair programming, but I've never heard it come from somebody who has done much pair programming. I've never tried mob programming myself, but I've done a ton of pairing, so I wouldn't be averse to trying this on occasion.

The hard thing about making software is not the typing, it's the thinking. And on teams, some of that thinking can be individual, but a lot of it has to be collaborative if the software is to end up having any real coherence. As Kent Beck writes, "division of labor is a dangerous fiction when all of your big problems are integration problems".

I've done a lot of good work alone in long, focused sessions. But I've done even better work in long, focused sessions together. Hands down the best code bases I've worked on are the ones where we did it all using pair programming while changing pairs every half-day or so.

View on HN

+1 to the comment here.

I see lots of discussions after code has been cut ('why this design?', 'why this library?', 'did you consider this?'), which would have been much more valuable to have as the code is being written.

With mobbing I'm thinking you can answer these questions and discuss opinions at the most appropriate time in the software creation lifecycle...

I found it incredibly stressful to try to answer those questions before I finished. Pair programming meant I could never try anything new, because I couldn't answer those questions immediately.

Huh. That hasn't been my experience. Often I've had a pair say, "Can we try something?" And I'm happy to say yes. I learned a ton that way.

I'll add that when I'm just messing around with something, that's often solo coding time. E.g., trying out a new library just for the fun of it, or playing around with approaches to a problem. But for me that's throwaway code, so I don't need the quality boost or the shared understanding that comes from pairing

> This is also basically the standard critique of pair programming, but I've never heard it come from somebody who has done much pair programming.

I've done a fair amount of pair programming and generally found it to be an inefficient waste of time.

Having colleagues around to bounce an idea off of is great, but there's almost never the need to have two people continuously coding together.

Ok. Now I've heard it from one person. But I think "there's almost never the need to have two people continuously coding together" is a pretty strong conclusion from one person's experience. Do you mean that you haven't noticed the value in it?

One possibility is that your team was maybe not so good at it. Sometimes that happens:

http://agilefocus.com/2009/01/06/21-ways-to-hate-pair-progra...

Another is that you were working in a domain where the benefits of pairing don't matter so much. For me, they include improved code quality, less siloing, making it easier to bring people on to the team, faster iteration, and a greatly increased ability to actually take vacations due to improved truck factor.

On long-lived code bases with high business value and fast iteration, quality and collaborative ease become very important to me. Basically, I put pairing in the same category as code reviews, but I think it's much more efficient. And others do as well:

http://slesinsky.org/brian/code/pair_versus_review.html

Count me in too. Worked almost two years of exclusive pairing. Other than onboarding new people to a codebase or ramping up juniors, it's the least efficient way to work I ever experienced. I don't have any formal metrics on code quality to compare there, but from what I can tell, the results were nothing close to "the best codebase ever".

Reply on news.ycombinator.com