Pair programming is one of the many Extreme Programming practices that I haven’t been able to use that much on my current project. We have a substitute dubbed ‘pairing’ which attempts to reap the benefits of this practice without incurring its perceived overheads. Part of ‘pairing’ allows us to pair program in certain circumstances (other factors prevent us from doing it actively all the time) and I recently had my first experience (or should that be an epiphany?) to reflect upon.
My first observation during this process was that I found the quality of code I wrote, and even my focus of what I was writing, increased tremendously. I also found myself absorbing more history and appreciation for the code I was adding to, instead of simply getting my tests to pass.
After enjoying my first taste of pair programming, I can conclude that to be really effective at it will definitely take a lot of practice. For example, one of my pair partners commented that I tended to unconsciously ‘huff’ while he was typing (probably because I can type much faster than him or was it because I found myself the victim of the Dominant Pair Syndrome?). Appreciating the feedback (of which I find myself so undersubscribed these days) I started to scour the net trying to look for some resources that described better pair programming etiquette. C2 Wiki has a good collection of resources such as ‘How To Piss Off Your Pair’, Pair Programming Questions, and Pair Programming Doubts. I’ve now added Pair Programming Illuminated to my wish list and am eagerly waiting for a copy of Peer Reviews In Software: A Practical Guide in my next Amazon shipment.
From an insider. Some things to make pairing easier:
1. Set your mouse acceleration to a reasonable level
2. Run less than 1400 on a tiny LCD monitor
3. Put smelly sport shoes and socks in the cupboard so your pair does not have to smell them
4. Move your deodorant and Worcestershire sauce bottle to one side
5. Thank a little helper that is getting you a brand new AMD64 with 17″ LCD monitor next week
Patrick, if you are getting frustrated at the typing speed of your pair, then you can ask to take the driving seat for a while. As you will have no doubt read, it’s bad form for a pair not to rotate fairly frequently throughout a session.
Of course, not everyone types as quickly as you, so some degree of tolerance will also be needed. A story should never need an uber-typer to be finished on time. If typing speed is a serious barrier to completion, then a problem lies within the estimation process.
Greg, thanks for your suggestions and I’m glad to hear all of them are simply environmental or physical aspects. My concerns about pair programming arise more from the behavioural aspects and social consequences that are much more difficult to identify and also much harder to change.
Love the fact that number 5 on the list will make number 1 and 2 obsolete. Now I won’t have to bring in my 14.1″ screen that has a native resolution of 1400 x 1050 which I know is difficult for some of my pairs to work with.
Andy, thanks for your tips too. I think that part of my frustration has less to do with the typing and more to do with trying to get an understanding of what my pair is thinking about. I know that it is poor pairing etiquette to continually interrupt them as they are typing (and thinking) so it is something that I think I will develop greater patience for as I practice pair programming more. (As a side note, although slow typing is frustrating for me, I realise that I have unrealistic expectations and that my frustrations shouldn’t have any negative effects on anyone else. It does remind me of the days when I used to tutor back at University, watching some of my students type…)
If you don’t know what your pair is doing, then ask, or get them to give a running commentary on what they’re doing, and what they’re thinking. I’m not talking about “I’m looking for the spacebar”, but things like “I’ve noticed that we’ve got a chunk of code that’s pretty similar, hmm, if I move a few things around, I can refactor that out into a method, what do you reckon ?”.
Pair programming definitely isn’t having a “typist” and a “watcher”. If the pairing is quiet, then it’s not going well, IMNSHO
Pat, pairing is a conversation and typing is part of the communication. If the typing is too slow or too fast to communicate what is going on then the vocal part of the converstaion should be filling in the gaps. Don’t be afraid to interrupt someone who is typing, you are meant to communicate as much information as you can to ensure that you both understand every aspect of the work.
I’m a slow typer and I’m sure it pisses my pair off occasionally (as Simon will probably tell you) but I try to make up for it by talking about what I’m doing and asking for confirmation that the path is the correct one.
Patrick,
In my experience the term pairing becomes a euphamism used by those that don’t _really_ like pairing when solving your problem without involving you/educating you in process.
When it comes down to it, pairing is about collaboration and, quite frankly, has little to do with the process and much more to do with personalities involved – there are those that like to pair; and those that simply tolerate it as a necessary inconvenience. Neither is better nor worse, just different. Anyone that tells you pairing IS necessarily better is misguided at best.
IMHO, it is most certainly NOT poor form to comment on what your pair is doing. The word PAIR is used for a reason. Anyone who can’t tolerate someone pointing out the mistakes should chill.
As for typing speed, I type a bazillion miles an hour and I’m often asked (nicely) to slow down a little and explain what I’m doing. I have no issue with this whatsoever and neither does my pair. It forces me to stop and think about what I’m doing.
I also get a little frustrated at slow typing but again, I don’t get bothered about it at all. I look at it as an opportunity to have a break and point out all the spelling mistakes and typos 😉
So if, like me, you _do_ like pairing, don’t be discouraged, just hope that you can find the right people to pair with that suit your personality and, if you can’t, understand that not everyone is the same.
Thanks for all the tips guys. I look forward to the next opportunity to which I can apply them all.