It usually begins with about 5 minutes of joking around and wasting time, but it takes only a minute or two to achieve flow. Individual programming can take 30 minutes or more to achieve flow. Once in flow, it is much harder to come out of it because you aren't tempted to browse to Hacker News. Also, no one will stick their head in your office and bother you because it looks like you are in a meeting.
Partners are incredibly helpful spotting errors and act as an extra cache for all the little details you need to keep track of. Usually the person not typing has a lot more capacity for those details because they don't need to spend the energy operating their editor and manipulating code (no matter how good you get at it, it still requires some brain power: a limited resource).
Also, when all is said and done, you now have TWO experts on a topic. Redundancy is a good thing.
Anyway, now that I don't have coworkers like this, I find it's easier to go off on my own. I also don't find it particularly useful to write a failing test and make it pass, I tend to alternate between big batches of code, a batch of passing tests, some todo tests, and then making that all work again.
YMMV, but you have to keep in mind that things like XP, Scrum, Agile, TDD, etc. are designed to make big groups do things in a consistent amount of time, so that the code works reasonably well and it is delivered in a predictable amount of time.
It is not necessarily a good way to do things if you are a good programmer. (Strict rules are for robots, not artists.)
"The amount of time you spend trying to figure out “what’s going on here” or “why isn’t this working the way I expect” is severely reduced. I’m talking hours of debugging that literally turn into seconds."
I'd attribute this very much to the extra "cache" of the second brain that isn't having to manage typing and editing as snprbob86 above mentions.
Have you ever watched someone searching for some piece of info on Google or Wikipedia, or looking for a phone number on a website? The person not wielding the mouse/keyboard can often parse and comprehend the info on the screen more quickly.
I also agree strongly with this: "the QUALITY of the code that IS produced is so, so, so much higher"
I think the post helps to dispel some myths of pairing as well, and it works best if pairing to reach the goal of completing specific tasks.
We used it mostly for collaborative design. It was helpful for bringing a new team member up to speed on our code base. We also used it as an interview technique, and that seemed very successful although that one hiring decision is weak evidence.
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.
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.
The places I've seen it work seamlessly has been where it averages out the work to a consistent level, whether all intermediate coders that no longer make rookie mistakes or all advanced ones that no longer slow down for newbie speed bumps. I've even seen pairs attack projects in programming languages they've never worked with before. I was brought in to Pivotal for an afternoon or two to give Flex/actionscripting advice to the programmers working on a friend's prototype site and they didn't need my help at all, I was happy to see that they knocked it out just fine.
On a side note, I just tried out pair designing this week (instead of programming) and it was a really interesting experience. You could see that we each had different focus (me = interaction designer, partner = visual designer) and that helped compliment our work rather than act as a source of friction. And not to get into a toolkit debate but we also shared similar philosophies about hating Photoshop and long design cycles, loving Fireworks and quick clickable prototypes, etc.
OMG, I just got an insight. I'm an effective Rover or mentoring "navigator" as long as no one expects me to read. I need to not look at the monitor, not try to read the code or docs or whatever. As long as all I do in the presence of talking people is do my own listening and talking, my brain doesn't turn to complete mush. I noticed long ago that I have almost zero reading comprehension when I read English (native language) aloud. I also remember covering my ears while reading silently when someone else reads or the teacher is talking. Etc. So the big insight is, my reading incomprehension in the presence of speech extends to reading computer code! I have a reading problem (or attention problem, or whatever it boils down to) which frustrates my ability to pair.
That explains why I have such a hard time understanding even a single line of code in most pairing sessions. That explains why, when I'm the "extra set of eyes," all I'm good for is syntax and spelling check (which really should be done by software, not me). Writing code happens to be a lot more of reading what's on the monitor than head's down typing. So, the question is, how am I able to drive okay with insightful and not-so-obtrusive Apoorva? Well, it often doesn't work. But I notice it does work when there's only one other pair in the room and I haul Apoorva and me to the far end. That cuts the other voices down significantly.
Thank you, thank you for prompting me to think this through.
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 think those of us who initiated pairing on our team were the most motivated programmers, and those who wound up pairing regularly were likewise the most enthusiastic about the project and about professional development too. I'll admit that it's hard to separate causes and effects here, but I do believe that on our project, pairing was more of an effect of our desire to improve our productivity.
If you know your IDE well enough, you probably won't need a powerful text editor to be effective (unless you are using a language that is not toolable, which is bad). And yes, your powerful text editor is feature poor.
You like what you like. He likes what he likes. You are in a mutually recursive Bulb paradox.
This, of course, assumes your IDE doesn't suck. Most do. If your IDE isn't powered by JetBrains, chances are it actually does suck.
(I could rant on and on about this, but I won't. Basically, if you haven't programmed seriously in a dynamic language, a functional language, Smalltalk with Squeak, Lisp with Emacs/SLIME, and Java or C# with an IDE, any commentary you have on programming languages and tools is worthless. You haven't experienced enough yet.)
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.
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.
Basically, when you pair, you get one better programmer instead of two lesser programmers. Think about the old 10x/100x developer question (http://c2.com/cgi/wiki?DevelopersWithHighProductivityTenxHun...). 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.
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.
That's why my preference is to pair on anything that is moderately challenging (or harder), and to work separately on the easy stuff.
This tends to happen organically.
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.
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.
