How do you pair?
Pair programming is something I have never figured out how to do. After almost two years at ThoughtWorks, this is still one skill I cannot do. I either end up watching someone else code or debating two different solutions trying to convince the other person that my way is right. I realize that both of these make me a horrible developer.
So, I would like some help. Hi, my name is Chris and I can’t pair.
There, I’ve said it. I have taken the first step and realized that I have a problem. Now if I could only figure out what the other 11 steps are to becoming a great pairer.
Here’s the thing, I keep hearing these stories about pairs who sit in front of a computer all day long, so much in the zone that they are able to right code telepathically. They never talk. They never argue. They never discuss and beautiful, simple code drips from the finger tips into the computer. Every line is surrounded by tests and their api’s will be studied from now to the end of time.
And then there’s me and my pair. I go to touch the keyboard and my pairs fingers are twitching above their keyboard like their life depends on entering one more line of code. I haven’t even written anything and they are correcting me.
So, I ask a simple question, “how do you pair”? How is it possible to work with someone so closely all day without stepping on each other’s toes and fighting about what it is that you are implementing?
I think my problem is that I am not an experienced developer (I’ve only been doing this for a few years compared to most of my pairs who have upwards of ten years under their belts) and I want to contribute something. I don’t really want to sit their and watch someone else type. However, the people I am pairing with don’t know how to pair either. They are used to sitting in front of a computer alone and banging out code.
And due to my inexperience and lack of pairing know how, I have no idea what to do?
I think the art of making pair programming work is having communication between the pair – this is generally achieved by the driver commenting on why/what they are doing and the navigator querying the driver when they are unsure what is happening.
I guess there has to be an element of light heartedness in the interaction otherwise it can be tough to work like that all day.
I guess a start could be to try ping pong pairing (http://www.magpiebrain.com/blog/2007/02/13/pairing-pattern-ping-pong-pairing/) to try and get a more even split in the keyboard time but it still requires some degree of talking otherwise I don’t think there is much value in the pairing process.
One of the least talked about aspect of pair programming is the personality match. I consider myself up-to-speed on pairing (just as Mark, I paired with him in London and he seems not to have been damged psychologically!). I’ve been in situations where the telepathic pairing happened but also like what you described, arguing a lot over design or coding.
What I notice is that partly this is due to development style and it tends to be easier pairing with other TWers because we all tend to practice the same things (e.g. TDD, DDD, etc.). The difficult pairing I had tend to be with client developers who are either new to TDD and pairing, or know the concepts, forced to practise them, but resist to fully embrace.
To me, this point more to whether one is open-minded about trying out new practices than skill levels. (Of course, having communication skill such as talking to your partner helps! The worst a dev can do as the ’senior’ in pair is *not* explaining why, discuss what, and debate how!)
Talking is a necessary part of pairing. I worry when I see a pair that does not talk to each other. Usually it means one of them has no idea what is going on.
Hi Chris,
If you’re itching to touch the keyboard, here’s something you can do instead: work out what problem your code will solve that theirs won’t, and ask them how they’d solve that problem.
I tend to ask novice pairs to “talk me through what you’re doing,” or “Have you written a test?” If they’re resistant to that, I suggest, “Can I write a test please? It will help me get a bit more context about the problem we’re trying to solve…” Then we’re into ping-pong territory.
I’ve had people correct me instantly, or try to insist that I use keyboard shortcuts, or just take the keyboard away and start typing while I’m still mousing (I’m a gamer, and prefer menus and mouse). In each case I tell them why I value their input, what the effect of the annoying behaviour is on me, and how they could help me better (sandwich model feedback).
Also – practice! Practice! Practice on stuff that doesn’t matter; breakable toys like the Game of Life or Noughts and Crosses are ideal.
First – don’t sit at the keyboard with no idea of where you are going. Have a design session at a whiteboard or with CRC cards to work out, with your pair, the general direction you want to go in, over the next few hours. This points you in the same direction, and helps ensure the navigator knows where the driver is going.
Second – share the keyboard. Have some agreed point at which to swap roles. One common one I’ve seen – esp. with junior/senior combos – is one person write the test code (usually the senior), and the other person write the production code. Another technique is to use a timer. Or you can break your work down into a series of mini-milestones, each of which should just be a few minutes (<10) – when you hit the milestone, you do a full build, check the code in, and swap roles.
Third – the navigator shouldn’t be passive. Navigators read maps. In a coding sense, this means that the navigator should be accessing a second computer (laptops are great for this role) and doing things like having the documentation for all the tools being used up and accessible. Anything that needs to be looked up – e.g. database schemas, documented requirements, etc – should be done by the navigator, preferably in advance of when it’s needed.
Thanks for all the responses, they are greatly appreciated. There are a lot of really good ideas listed above.
As for the talking bit, that is a given. My comment about the telepathic pairing was because I have heard on two different instances pairs who were so in tune that they didn’t need to talk held up as the pinnacle in pairing. I personally find this frustrating as it sends the wrong signal to people.
@Robert – I like your suggestion of spending time doing design before starting to code and I have tried this when pairing. Some of my frustration and comments come from one pair I was with recently where we spent quite a bit of time doing design and then when it came time to coding, he basically told me I was doing it wrong.
As for the sharing the keyboard thing, this is harder to do when both pairs have keyboards in front of them. And this may be the biggest problem. When you are pairing with someone, how do you resist the urge to correct them and start typing when you have a keyboard and mouse right there in front of you. And I am as guilty of this as the people I pair with.
I think I need to understand the whole concept of driver and navigator. To me, the navigator isn’t doing anything. They are just sitting there correcting everything that the driver does wrong. They point out spelling mistakes, syntactical mistakes and so on. They really aren’t engaged in developing the code. For me, this seems to be more apparent because we not developing code. We are just adding features which mostly means adding a few lines here and there and adding a test or two.
I still have a lot to learn, but the advice above helps. Thank you
With respect to the roles of the navigator and driver roles, I posted a little bit about this earlier this year (http://www.markhneedham.com/blog/2008/02/14/pair-programming-the-non-driving-pair/)
Probably more valuable though was a comment Pat Kua wrote on the post:
See if you can track down a copy of Pair Programming Illuminated. It describes different styles of pairs working together and when pairing works against instead of for.
I have a few suggestions for improving your skill as a “navigator” (another name given to the person not actively coding).
Rather than just dive into the tiny tasks – have that design discussion with your pair about what is the best way of approaching whatever you’re working on. A result of this might be tiny tasks. If it’s straightforward, then you can simply review the tiny tasks.
When you’re not driving I find it’s useful to step back and ask a few questions to myself. Is the testing strategy right? Is there excessive duplication? Would some other person come along and find this difficult to follow? Does it look consistent with the way the rest of the application? Are there more tiny tasks to find and add to the pile?
One other thing I find useful to do when acting as a navigator is to share tips around the workspace such as keyboard shortcuts, various tools (I see you do this – did you know you could do it quicker if you used x?).
If you don’t find yourself adding value or if your pair doesn’t feel like you’re adding value then maybe you should reduce the amount of pair programming time.
Hi Chris – I love your opening sentence. While I don’t want to re-hash everyone else’s comments, here’s a few thing to make pairing easier for me as while I was learning it.
1. Ping-pong pairing is fantastic; each person is involved. Try dividing up the work where one person writes the tests and the other makes the tests pass. If you are the lesser experienced, make the other person write the tests and you just do the simple things to make them pass.
2. Setup your pairing station where you are sitting across from one another instead of shoulder to shoulder. Also, make sure each of you have your own keyboard and mouse.
3. Always ask why. Always talk through the problem you are facing rather than keep it in your head. If you talk through your problem, you’ll find it will turn into a conversation and the code begings to appear!
Good luck. Once you get into those pairing zones, there’s nothing like it!
I find that the hardest time in the world of pairing is when you are new to a codebase. It’s not a matter of 2 years versus 10 years; it’s a matter of being new to the codebase, and not knowing where to look for something or where changes are supposed to be made (or you’re new to the domain, etc).
If you feel that you can, try to be open with your pair about what you want. Say “I haven’t been driving much recently, do you mind if I drive for a while?” If they don’t agree, you have a pair that isn’t compromising.
If they do agree, but take control back too soon, ask them to tell you what you should do, instead of taking over, so that you can continue to drive.
If you feel that they are correcting you a lot, and taking control to show you the “right” way too often, then I would ask them to give you some time to try to get some functionality working, and then you can let them refactor it to what they want. When pairing, you want to avoid getting stuck on a disagreement and not complete anything. It doesn’t have to be perfect the first time (and it probably shouldn’t be).
That being said, if you are too passive, then some people may assume that means you want them to drive (or that they can get away with dominating the pairing situation). When faced with an aggressive pair, I try not to sit back and let them drive it out all day. Instead of asking them to go to some code that I want to look at, I ask to take control so that I look at something. I’ll explain to them what I want to look at, and if they try to continue driving, I’ll ask them again for some time to look at it myself.
One final note, pairing with 2 keyboard and mice is way, way better than with one. It allows you to not have to ask for permission to take over. On the downside, an aggressive pair can take control back quickly as well. However, as a last resort, it allows you interfere with them if they ignore your requests to take control. It’s rare, but I have paired with people where I purposefully interrupt there control of the mouse and keyboard and pretend it was accidental. When I do this, I’m trying to force them to accept that I’m there, and I will eventually drive. If they let me drive more often, I’ll interfere less when they drive.
The last part may sound childish, and it kind of is, but I’ve had decent results with it, just make sure that you and your pair are being professional and getting work done. Also, if you don’t feel that it’s getting better and you and your pair are just clashing, you may not want to continue with this approach.
By far, the hardest pairing situation is when the other person isn’t interested in compromising at all. There isn’t a whole lot to do about this in my opinion. Some people aren’t interested in being good pairs. I avoid those people if I can.
Also, when you are new to a codebase, it’s helpful to have some non-pairing time on a task or card so that you can spend your time moving around and learning at your pace. Request a little alone time if you feel you need it, or if you need to get away from someone you can’t stand to pair with.
Pairing is like a relationship – both people have to participate in making it work, and communication is important. If it isn’t working out, it may be time to break up.
Hi Chris,
Looks like your site doesn’t accept trackbacks, so here’s my responses. It’s a little long to post as a comment:
http://www.thekua.com/atwork/2008/12/how-i-like-to-pair/
Good luck!
There is a lot for me to think about in all the comments posted above and in the various blog entries that I have read. Thanks to all for the help.
@Kris – Your point about finding time alone to figure out the code base hits squarely on one of my frustrations. I am new to the code base, and new to programming, and the people that I pair with have a tendency to get frustrated with me when I want to take some time to look around.
I fact, I have noticed that the people I pair with get frustrated and antsy whenever we are in an area that they have a specialty in. I was pairing with one person and we were doing some linux stuff and he constantly kept correcting me and sitting there with his fingers itchy to “do it the right way”. The result of this is that the other pair doesn’t learn.
Actually, now that I think about it, I think the problem is that pairs, myself included, are not willing to allow the other person to make mistakes. We know how it should be done and we are going to see that it is done that way regardless. I think this week I will work on allowing my pair to implement their ideas regardless of whether I think they are the right way. Most of the time, they know more then me anyway and I am the one making the mistakes.