The cases where I found pair programming to work really well were during major refactoring efforts on large bodies of low-quality legacy code. We were just trying to get the codes bases up to current corporate standards so that we could then have a solid foundation for future improvements. It's tough to stay motivated on a mind-numbing (but necessary) task like that, so having another programmer right there helps to keep both on track. Plus it's easy to make a subtle mistake that wouldn't be obvious in a code review later, so another pair of eyes watching the refactoring live was helpful for catching unintended changes.

I've tried it in other circumstances as well but it ended up seeming like mostly a waste.

Pair programming never worked (overall) for my partner and I. Generally, I found both participants have to be extremely focused, have roughly the same skill level, and the code should be worked out on paper before "iterating." Otherwise, we ended up arguing over trivialities or bird walks over to youtube in the moments where we both were stumped (more my partner--I'm not a big fan). Long story short, we use pair cowboy programming now with more success. I guess it's all dependent on the cohesion between partners' attitudes towards work; if partners' ethics are different use logical cohesion on a project else use functional cohesion (which is definitely preferred but not always an option). Hope that makes sense, just my limited take on the topic. Does anyone have any success stories with pair programming--I could use the tips!

I definitely recommend keeping sketchpads, graph paper, and a chalk/whiteboard around. It gives us a new mode of thinking in addition to plain old code.

We have two 2x8 ft dry-erase boards actually. They have helped immensely during past meets. Surprisingly, Google Wave has helped us organize our collaborative coding a lot; Wave even has a brainstorm app (digital sketchpad) built into the client now.

My (very limited) experience with peer programming:

- It works very well if both of you are experiencing a language for the first time so you can both help each other with syntactical traps that you may find yourself in as well as other quirks that emerge with new languages.

- It doesn't work as well for projects in which you both know how to code. Having another person watching you code over your shoulder is distracting and stressful, and often it would be more efficient for that second person to code simultaneously with you.

However, these are only my experiences, and I'm sure they change from person to person. I'd recommend that everyone try it at least once - it may work for you, and you probably won't know until you try.

If the most complex problem you have when coding is getting the syntax right then you aren't writing very complex code.

I pair code fair bit at work, and it's because other people can spot the mistakes in design that are made very quickly, because they aren't focussing in on the specifics, and so can keep the big picture in mind.

This article really hits the mark. I wish more companies would adopt a pair programming discipline. My experience with it has been largely positive. It takes some getting used to, at first, especially getting down a good system for reading code aloud and directing each other's attention to a particular location in the code.

After a while, it feels pretty natural. And productive. Also, there's less burnout, more useful socialization. We've also gone the Nerf gun/slackline/juggling balls route for taking quick breaks between chunks of features. After the first person you seriously pair program with, it becomes easier in general. You're free to find your own similes.

It's easier to flow. See http://www.c2.com/cgi/wiki?MentalStateCalledFlow and http://www.c2.com/cgi/wiki?MyMindKeepsWandering

Pair programming is programmer abuse. Two people are rarely the same competance levels, so either you end up teaching or slowing someone else down. All the merits of pairing can be achieved through other, more efficient means.

You convinced me, but:

- how often do you change seats?

- don't you feel extra tired at the end of the day because of all the constant input and discussion?

A. Actually we don't really change seats that much, but we do change 'drivers' so each of us takes turns to type in stuff, but again this isn't based on any specific guideline.

B. Yes, it is slightly more taxing than working solo, but the advantage is that you feel more productive and better about yourself because you've completed a lot of stuff in a day.

Just to illustrate this - we've done four sprints of one-week each so far, and in every sprint we've achieved more than we had planned to do (even though are targets are quite ambitious).

A) It depends on your dynamic. I've found that with people I don't know that I tend to switch very frequently (10 minutes) whereas with my long time pairing partner we can go much longer (60 - 90 minutes) without switching.

B) Yes! It is definitely more taxing. That's why there is the idea of the "Eight Hour Burn." Pairing takes it out of you.

http://www.c2.com/cgi/wiki?EightHourBurn

just what is it with blogs and gray-on-white text these days? what's wrong with real black on real white? does everyone have a miscalibrated super-glossy-glare highdef screen or what?

Ok, so are there any Bad Things?