Nowadays I intentionally pair all of the time and I can say with confidence that it has made me into a better programmer, communicator, and team mate but not all of my experiences have not been pleasurable. I have found that pairing, like many XP practices, is easy to get wrong. Project teams misunderstand and abused this practice in terrible ways.
Inspired by my colleagues @moss and @lgdean who put together a presentation on pairing, I decided it was time to start compiling a list of "pairing smells" that I have experienced over the years:
Pair Stenographer - A driver who has no opinion on the subject. The navigator dictates code while the driver types. The crazy thing is that there are companies out there actively searching to fill this role!
"Pair Programmer is an apprenticeship position whose primary responsibility will be to support one of the company's founders - whom will call the Senior Programmer for this description - in the design and implementation of software products. The Senior Programmer will dictate code in python, C++, or other languages to the Pair Programmer." http://newyork.craigslist.org/mnh/sof/1645696541.htm
"We're Lost" - This is when the navigator does not know what is going on or how we got here. As the navigator you should always know where the driver is taking you. If you do not know where you are ask the driver to "pull over" so that you can figure out what the current task is and review the changes in your current change set. Then produce a "map" of where you are headed so that you do not get lost again.
"I don't need directions" - The driver wants to change things ignoring any direction from the navigator. This usually happens because the driver does not respect the navigators programming skill. In this case the best thing for the navigator to do is pull the driver aside and give them direct constructive feedback. Diana Larsen and Ester Derby offer an excellent course where the participants are taught various techniques for providing others with feedback.
Pair Copy Editor - "You misspelled that... You forgot a semi-colon...". Navigators, please be patient and let the IDE, compiler, or test tell the driver what is wrong. The driver is not going to get you both killed if they forgot a semi-colon.
e-mailing, texting, and talking on the phone - It's rude. Excuse yourself and go somewhere else.
Watch me look this up - At times innocuous, but pair researching can be a waist if you're both doing it using one workstation. Split up and perform the search simultaneously. When one of you finds something let the other know.
"What if I want to get a sandwich?" - Not everyone is on the same schedule. If you are hungry or have to take a bio break, do not feel compelled to stay at the workstation. It's OK if someone solos for a while.
"Want to pair in my (cube | office)?" - I cannot tell you the number of times I have declined these invitations. The guest is always at a disadvantage. Level the playing field by either setting up a shared workstation or use remote pairing and share desktops.
Pairing as training tool - I often hear people who advocate pair programming say that it is a great way to train new hires. In practice it is a not effective. Bad pairing is not a substitute for good training. When you hire people train them, otherwise your team may find them to be a burden and it has a poor effect on morale.
That's it for my first list. What "pairing smells" have you caught a whiff of?