Aside from physical, eyesight, accessibility, noise, etc. problems, I pretty much can't stand pair programmming. It's good for social bonding and instructing noobs, but my work is hardly up to snuff.<p>I can't "navigate" someone moderately competent because it takes me forever to stuff a pile of someone else's code into my head. I have to keep scrolling here and looking there, which I can't do without a separate keyboard and monitor. I want to navigate from an extra computer so I can flip through the code, look up docs, and so on. But, by gum, that's not "pair programming." Hence, the only thing I'm good for as a navigator is catching syntax and spelling errors, which is something an appropriate editor or IDE can do.<p>And I can't accomplish much while I'm "driving" because either I have to spend all my time explaining everything to the noob, or I'm not allowed time to think. If I stare into space or scroll around a bit, the navigator thinks I'm stuck and feels compelled to chatter away with advice or questions or something. And unlike the author's "Progammer Man," the code I produce solo in the Zone is better than the code I produce in a pair out of the Zone. The best "navigator" is someone who watches awhile then gives up and "pairs" with someone else! No, I take that back. Apoorva is a decent navigator. He mostly just sits there and makes a few pleasant quips, occasionally raising an insightful question. I guess I'm very, very finicky about navigators.
Does it make you more productive or do you just find it more fun?<p>I suspect companies that institute pair programming because employees are less likely to goof off when they have another set of eyes on them. I have a hard time believing that it actually makes motivated people more productive.
I pair programmed with a friend all the way through my graphics class. It worked out really well because my linear algebra was really strong and his C powers were unstoppable. We easily finished in half the time of other groups. I'll provide more detail when I'm not on my ipod.
The vi analogy was really stupid. If you know Vim(not Vi) well enough, you probably won't need an IDE to be effective(unless you are using an IDE dependant language, which is bad). And yes, your IDE is bloated.
I've learned programming this way with a good friend, even 28 years later we're still in touch.<p>It's one of those things where you can see how much it matters that you can rely on each other to catch stuff before it becomes a dead end, when you're programming on your own it's very easy to waste some time every now and then, and to have to backtrack later.<p>If you can't actually program pair wise I'd certainly recommend that you go over your design with somebody competent before you commit to code, you'll be surprised how much time that will save in the long run.
My theory on pair programming: a good pair is _more_ productive than two individuals on hard tasks, and _less_ productive on easy tasks.<p>Basically, when you pair, you get one better programmer instead of two lesser programmers. Think about the old 10x/100x developer question (<a href="http://c2.com/cgi/wiki?DevelopersWithHighProductivityTenxHundredxThousandx" rel="nofollow">http://c2.com/cgi/wiki?DevelopersWithHighProductivityTenxHun...</a>). In reality, it isn't that simple. A 10x programmer won't write simple code (Hello World) 10x faster. On the other side, a mediocre programmer may be unable to do some of the things that a better programmer can do, no matter how much time you give them. So it's silly to compare productivity along a linear scale like this.<p>Pairing is similar. It's meaningless to say that a pair 2x as productive as 2 developers, or 3x, or 1.5x, because it depends on the task. They might work far faster at a complex problem, but no faster one programmer at an easy one.<p>That's why my preference is to pair on anything that is moderately challenging (or harder), and to work separately on the easy stuff.
Having another programmer around to talk me through a gnarly bit of code is often enormously helpful.<p>This tends to happen organically.<p>When it comes down to the heads-down time necessary to plow through some changes, a second pair of eyes hovering over my shoulder becomes a distraction and a productivity killer.<p>There exist shops where the mantra is "Pair Programming = Good" and you are encouraged (and socially pressured) to do most or all of your coding at a single screen with someone else. I tend to do not so well in these.
Personally, I love pair programming because I feel like i'm learning more faster. Some of the more experienced engineers I've worked with passes some insight and knowledge, which has been a huge benefit to me.