Pair Programming Gone Bad

Moved from PairProgramming:

Admitted, I haven't read the books yet. I've done things that sound a lot like pair programming before, and they were disastrous. I found myself less than 1/3 as productive as normal because my SignificantOther needed so much hand-holding, explanation, language lesson, dispute, history, ... I spent the bulk of my time justifying each line of code, with destructive effect on my ability to hold a thought long enough to develop it. If you need to explain each line of code in that much detail maybe your code is TooComplex? I agree that not everyone will start out at the same speed but PairProgramming should iron that out fairly fast. But will it also iron out the order of magnitude differences that can exist between programmers, in terms of skill/ability? I think not. It's not some kind of IQ equalization device!

''I don't know why people defend this practice. Those who like it where I work seem to have convinced themselves that it works and I see them struggling everyday. No Pair Programming != No communication and I think many fail to realize that point.

The experiences succeeded only when my SO hushed up and let me work, or when I returned the favor. In other words, they succeeded only when the pair dissolved. It's worked much better for me to run interference, defending my SO's solitude from others while [s]he got the job done (or accepting the return courtesy.)

I really do like working in teams, but with more division of labor. Let me do what I do well. Help me by providing others who do well what I do badly. (This is reflexive by the way - I want to fill in others' lacks, also.) Keep the clutter out of my way, and I'll try to stay out from under your feet, too. For me, good fences make good neighbors.

I don't dislike the pair programming idea. I just find it as incomprehensible as the idea that I should program while hanging upside-down by my heels. What is supposed to make it work?

You're supposed to get tired and make mistakes. If you get tired of detailed thinking, your partner takes the keyboard and you get to design for a while. If you make mistakes, your partner catches them in a small fraction of the time it would take you to catch them. I find that the "level set" discussions about formatting, approach, and IDE rapidly disperse (in a matter of days).

TestFirstCoding? helps pair programming by making sure you know you're solving the same problem before you argue about how to solve it. -- tvancourt

Perhaps it would be helpful to consider that PairProgrammingIsDoneByPeers. -- RobHarwood

I have personal experience with the PairProgramming method and it works. Well.

However, I think finding the partner with whom you have that telepathic connection could be the hardest part. And there will always be folks who want to work alone.

And as Don (see above) hinted to, trust is a big, big factor. You have to trust your partner and know them well. They will come to know you very well too.

As far as I am concerned, this and ContinuousIntegration are the 2 best lessons of ExtremeProgramming.

RonPerrella

 The experiences succeeded only when my SO hushed up and let me work

 I think this is why you had a bad experience, the key to pairing is communication. Let's define the 2 roles

 Driver : the person at the keyboard
 Navigator : the person with the solution

 The rule : for something to get from your head to the computer, it MUST go through the OTHER person.

 In your above statement, you are being both the Driver & Navigator. You are probably being frustrated by a couple of things.
 With a beginner, or in the beginning, you will have to pair with something much more like dictation. 

 i.e. 
 Nav : We need to iterate thru and find the first match.
 Driver : (blank stare)
 Nav : Create a for statement.
 Driver : for(int i = 0; i < 
 Nav : values
 Driver : for(int i = 0; i < values.length; i++)
 Nav : if it's equal return it
 Driver : if (values[i] == expected) {return values[i];}
 Nav : no, return the index
 Driver : return i;

 With more experienced people this becomes
 Nav : return the index of the first match
 Driver : for(int i = 0; i < values.length; i++)  {if (values[i] == expected) {return values[i];}}


 Notice that at either level the Navigator always gets to keep his eyes looking at a bigger picture than the driver does.

As your skill in Navigating grows you can move at an unprecedented speed. The person who 'sees' the solution for a particular feature usually stays the navigator throughout the feature, as it is extremely hard for the driver to gain the speed needed to both type the current step (return the index of the first match) and figure out what the next step is.

LlewellynFalco

It sounds more like baby-sitting than pair programming. Unfortunately, managers do occasionally replace real training with this very thing, wasting your time and their resources.

Although it may be possible to do pair programming well, it is not intuitively obvious about how to accomplish it. My attempts to introduce pair programming have been disastrous.

In general, peer programming seems to be an implementation of MicroManagement at its worst being performed by those who have no management authority. The pairs became largely a dictator (meaning talker, not necessarily despot) and a typist. People objected to someone telling them line by line what to type in especially by someone they only considered a peer, i.e., with no authority to tell them what to do. Even the individual who was most cooperative said that he couldn't wait until he "knew enough to not require constant hand-holding."

I am not sure what benefits pair programming is supposed to bring, but the emotional costs are high enough that I do not plan to ever reattempt it.

-- WayneMack

I think the point is not that you have a dictator, but an assistant. The partner not at the keyboard should never be dictating line by line what to type. Instead, he should be managing the GoalStack. "Don't forget to test the foo combination"; "Would this be easier if that other object could bar?" as opposed to "Don't forget to test that foo and baz are equal when we call it in this order", or "That object needs to bar in this way, so that we can write this code in this other way". --WilliamUnderwood

Why would anyone want to sit and type in code with someone criticizing everything he types in? Frankly, if I had to sit at the keyboard listening to comments such as those above while I'm trying to do my best to get the code to work, I would get up and leave. It isn't criticism though - it is high level direction. When coding, I tend to lose sight of the big picture. And after a coding session, the roles change and I get to stand back and help with the direction.

When I hear words like criticizing and dictator in this context I start to wonder if your workplace isn't somewhat disfunctional. PairProgramming works well when everyone works well together. Our developers pair, at-will, and enjoy each others input. As a result we not only hire people who are competent programmers but good team players.

CategoryPairProgramming