If you look for pair programming definition in Wikipedia you’ll see a very concise and detailed definition of how pair programming should be done. in my experience there are several ways to program in pair and they vary not only between different companies but also with different pairs at the same company.
The following is based on my thoughts and observation and should not be taken too seriously.
In pair programming there are two distinct roles – the code writer (a.k.a. the driver) and the one who doesn’t write code at that moment (Passenger). in pair programming the driver suppose to write code while the passenger reviews it on the fly.
You’ll know a “backseat driver” pair due to the frustrated look on the driver’s face. The source of the frustration is that the passenger keep interrupting him commenting on every-single-line-he-writes. You’ll hear the passenger saying phrases such as: “This is a good idea but perhaps we can do X”, “On second thought we should…” being repeated over and over again.
If you work with such a person – keep in mind that he means well – he has great ideas and need to express them, one option is to let him drive for a while. If the problem persist tell him that you’re going to do X right now and later if it will still look like a good idea to do Y instead – you’ll refactor!
You know the type – the impatient developer that gets so excited by the code written that he must grab the keyboard and write code – right now!
Sometimes it happens because your co-worker knows the task better or because he has some kind of ADD, regardless of the reason working with such a person can get very annoying very fast. Be advised – as strange as it sounds this guy may not even notice that he behaves this way, in fact next time you have pair program stop for a minute and think – are you doing that right now? I know I used to.
There are some ways to handle this situation – if you’re feeling assertive you might be tempted to “fight fire with fire” and retaliate by steeling the keyboard back when opportunity arise – this might even work! I saw several such pairs and they had an harmony of sort that worked for them.
Try to set some ground rules – there is nothing wrong with telling your pair that for the next 20 minutes only you can touch the keyboard or at least let him know that his behavior annoys you and is counter productive. And if nothing else helps – try to keep the mouse (and keyboard) as far away from him as possible…
This guy take on look at the problem and starts writing code as if his life depends on it. If you pair with this guy you might have a feeling that you spend most of the time eating his dust.
first you need to STOP HIM, make him understand that he lost you three functions ago and make him explain what he just did.
It might be a good idea to let him rest a bit as in the passenger seat while you write some code, but beware – a sprinter can easily become a keyboard grabber so you need to set a fast pace so he wouldn’t get bored.
You’re the driver and you’ve been coding for an hour without even a single word from the other guy, when you look at him you notice that although his eyes are open he’s sound asleep code-wise. You might have run too fast (because you are a sprinter) or you might be working in a domain that you know better – it doesn’t really matter.
The way I see it you have two options: you can act as if everything is perfectly fine and keep on working – not exactly living up to the pair programming methodology, or you need to make him part of the code – fast.
If you’ve decided not to be a selfish pig you have several options – you can give him the keyboard and let him code for a while. If you practice TDD (Test Driven Development) try this “game” – your job is to write the test and he has to write the solution, this way nobody is left out and both of you have “keyboard time”.
I don’t think there is a bad way to do pair programming – I’ve seen successful pairs that found the right dynamics that worked for them – a pair of two “keyboard grabbers” or sprinters might actually work, there are no rules – some developers will strictly follow the methodology and some will find a way that will work for them.
The bottom line is you have to make sure that the person you work with will want to work with you on the next task as well.