The Joy of Two (pair programming)

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!

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.

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?

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?