This is the area which has been written about the most, perhaps because it’s the most visible to others.

Knowing your IDE and its' shortcuts, taking lots of small steps, using TDD, ensuring that both people get keyboard time, keeping a list of tiny tasks, and so on are all ways that we can work more effectively as a pair.

In addition, it’s also important not to spend your time arguing because your pair doesn’t do exactly what you want them to do. Cam Swords nails this in his comment on Dahlia’s blog

One idea I learnt from reading Steve Pavlina’s blog, also touched on here, was that whatever we want to happen, we should do more of ourself and it will naturally happen. Therefore if we feel our pair is not listening to our ideas we should spend even more time ensuring that we are actually listening to them - I don’t always follow this advice myself but when I do it does seem to work.

Stepping one level up, it’s also useful to ensure we rotate pairs frequently to ensure that a pair doesn’t become stale or get sick of the sight of each other! I don’t have the data to back this up but I think at most we should be looking to rotate at least every few days if not more frequently.

I know the majority of the time we are pair programming in a work situation and although maybe we take a slight short term productivity hit by having this element of fun, I think working in this type of environment is more conducive to success in the longer run.

If I enjoy the work I do I’m likely to be more passionate about it, learn more about it and therefore become better at doing it.

Some examples of ways to create a fun atmosphere when pairing could mean joking about stupid variable names that you have come up with or having a side conversation that you pick up when there is a lull in proceedings - when the build is running for example.

Having a fairly laid back approach and not taking the whole thing too seriously is a useful approach to take. Being able to joke about the bad code that you’ve written and then working out ways to improve it with your pair can be a fun learning experience when done in a laid back way with a pair that you trust.

Clearly there is a bit of a balance to strike here so that we do actually do some work - although it is sometimes fun to include other pairs in our banter, doing so all the time doesn’t work so well from my experience and ruins their train of thought.

Although a lot of the value in pairing comes from the fact that we are spreading knowledge around the team and having two eyes looking at a problem tends to result in better quality solution achieved more quickly, I think teaching our pair new things is also very important.

One of my favourite phrases that I have heard with regards to judging the success of a Project Manager is to look at each of the members of their team and see if they are better for having done the project than they were before. If they are then the Project Manager has succeeded from a people point of view.

Maybe we can apply the same logic when pairing - in every pair programming session always look to teach your pair something that they don’t know. It doesn’t even have to be something completely related to the story being worked on although it’s even more effective if that’s the case.

It could be as simple as pointing out some books or blogs you have read recently around an area of technology which you know is of interest to the other person. Sharing domain knowledge in areas which are maybe not immediately applicable is another way that we can help share knowledge with our pairs.

I’m sure there are other subtle gains we get out of pairing that I haven’t thought of, but I think it’s important that we constantly look for ways to improve the way we pair.

For example, I recently came across the idea of screen pairing from Brian Marick’s blog - an idea that he learnt when pairing with Corey Haines on Corey’s pair programming tour across the US.

The idea is that both pairs sit at a machine opposite each other but both see the same screen by using iChat. The thinking behind this approach is that you can more easily see your pair’s body language and that it is generally more comfortable than having both people sitting side by side. Certainly an idea to try out in a Coding Dojo type situation.

I’m sure we haven’t yet learnt all the tricks of mastering this skill so keeping an open mind is probably the most approach at this stage.

I still have a lot to learn about pair programming and these are just some of my observations so far. Coming from someone who is very much pro pair programming, we want to try and reach the stage where we can prove that there is more value to the business from having our developers pair than by having them working individually.

We can only do this by continually evaluating what we are doing and looking for ways to improve it.