[programminggeek]

Some people hate pair programming. I happen to be one of them. It kills my personal job enjoyment/satisfaction and if I was coerced into pair programming too often, I would find a job elsewhere.

So, the cost of losing one or both of the programmers in the process must be considered too.

[BurningFrog]

True. It's also true a lot of people hate solo programming, and do not want a non pair programming job.

My other point is that pair programming is a learned skill. If you just put two unprepared programmers by a computer, you'll most likely end up with two annoyed programmers, and not great code.

[Silhouette]

My other point is that pair programming is a learned skill. If you just put two unprepared programmers by a computer, you'll most likely end up with two annoyed programmers, and not great code.

This is a popular argument among pair programming enthusiasts, which suggests there may be some merit to it. How do we reconcile it with another popular argument, that many programmers will naturally pair up on an ad-hoc basis when they're working on something challenging and/or interesting?

I can't imagine not wanting a second opinion from time to time, and I've certainly missed having one sometimes when I've been working solo on something and there was no-one else to talk about it with. But personally, I also can't imagine being comfortable in a full-time pair programming culture with necessarily restricted schedules and limited solo time. Sometimes, I just want to do some research or think through some ideas or play with quick and dirty prototypes for a while, even if I might be very interested in discussing my results or initial conclusions with other interested developers afterwards.

[BurningFrog]

> How do we reconcile it with another popular argument...

I don't think I've heard this argument, and I haven't observed programmer behavior in the wild :)

I'm happy working solo 1 day a week or so, to do things maybe only I care about, or explore/learn things.

Pair programming certainly isn't for everyone, but don't knock it until you've done it for a few weeks, hopefully with some good pros!

I've never learned so much about programming as during my first ~6 months working together with people and learning their wisdom and tricks.

You're right that the restricted schedules are a downside.

[Silhouette]

I've literally never worked for any employer in any development role where spontaneous pairing or larger group collaborations didn't happen often. It's just human nature. I see others commenting in this very discussion with similar anecdotal experience, so apparently I'm not just completely weird in this respect.

I don't doubt that you can learn a great deal and obtain other benefits as a result of pair programming. I'm just questioning whether making it a formal, quasi-full-time arrangement is necessarily better than the ad-hoc version I see happening all the time for similar reasons and with similar benefits.

[BurningFrog]

We may just mean different things by pairing.

Sure, people help each other in various ways in most places. But that's the solo programmer on a task asking someone else for help. Two people work on a something together, from start to finish, is a quite different thing

[Silhouette]

Just to be clear, I'm talking about two (or more) developers, gathering together to solve a problem collaboratively, with the end result that the code to do so is written or at least the significant questions have been answered and what remains is little more than a mechanical exercise. But I'm talking about that happening spontaneously, and not necessarily starting from a complete blank slate, being done on a specific schedule or according to any specific process or using any specific tools, or being required as formal policy.

[fennecfoxen]

Next time on Hacker News: an article about the economics of strong typing, with someone threatening to quit if they have to use a strong typing system, demanding that be factored into the economics as well.

Perhaps true, but not really the point the authors were looking at.

[CodeMage]

If you look at @programminggeek's point without passive-aggressive exaggeration and then at the wiki, you'll see that it's specifically called out as a potential problem.

Sadly, it's dismissed out of hand as a "people problem" and "irrelevant". It really deserves more attention.

First of all, if you're looking for programmers to maintain a VB6 app, you really should factor into the economics of that endeavor the fact that most people don't want to code in VB6.

Second, no matter how potentially beneficial the pair programming approach is, there is a question of psychology in play. There are people who are introverted enough that the constant company required for pair programming will wear them down and cause them to quit or change teams. Dismissing it as a "people issue" and misrepresenting it as being unable or unwilling to be a team player is an oversimplification.

[commandlinefan]

I don’t know if I would say I “hate” it, but the one time I tried it (at the behest of my then-employer), I and the rest of my team found it to be unworkably impractical. We had half as many computers as we had programmers, so we each shared a workstation. However, each of us had our own individual e-mail addresses, so we’d have to take turns checking and reading e-mail while the other one sort of looked away. When we started using something new (I think it was Apache Struts back then), we’d have to take turns reading the documentation - we even tried putting two different copies up side by side so we could scroll individually (but we still had to take turns moving the mouse). Beyond that, everything seemed to take way longer than it might have taken individually because neither of the people in the pair would be comfortable doing anything experimental unless they could quickly explain it to the other, so there was a lot of time spent talking about whether some approach or other might work instead of just trying it to see what happened.

[couchand]

There are so many anti-patterns here it's painful...

If you're pairing, don't read your e-mail. Even if you're just in a solo work session, don't read your e-mail. It's incredibly disruptive and constant inbox checking will drop your productivity like a rock.

It's okay to pair with multiple workstations (or a single workstation set up for multi-user mode, that's the dream I guess). Looking away from the "main screen" to check docs (or VCS, or the build, etc.) is perfectly fine, just don't get drawn in so deep that you forget about your partner. And certainly don't use that as an excuse to check your e-mail or slack!

One strategy to apply is "show, don't tell". If you have a hard time explaining what you're going to try to do, just do it, the code will probably be clearer than your explanation alone. If it's not, use the conversation to drive the uncovering of assumptions, which can then be encoded in the source.

Remember that pairing isn't simply two people, one keyboard. There are defined roles: the driver and the navigator. The driver handles mechanics, the navigator observes and questions assumptions. Then switch roles. The driver should fearlessly try the experimental things. If the navigator wants to experiment, ask to drive.