Mark Needham

Mark Wilden pointed me to a post he's written about his experience pair programming at Pivotal Labs where he makes some interesting although not uncommon observations.

When you pair program, you're effectively joined at the hip with your pair. You can't pair if only one of you is there.

I've previously written wondering what we should do if our pair isn't around where I was leaning more towards the opinion that we should try to continue along the same path that we were on when working with our pair if they're gone for a short amount of time and to find a new pair or work alone if they're gone for longer.

On the projects I've worked on we'll still have times working alone when there's an odd number of people around or if someone just feels like working on their own and I think that's fine as well. I don't think we need to pair 100% of the time.

You have to be able to think out loud – 8 hours a day. Then you have to type in code while someone is watching you. They'll catch your typos (hopefully after giving you a chance to spot them yourself) and they'll see when you're floundering for how to do something.

I find that this is quite a useful practice for explaining things to yourself although I can see how it would initially exhausting.

Even now there are times when I just want to write some code instead of having to explain what I want to do to someone else. Sadly almost every time I explain something it turns out that my pair has a better idea of how to do it than me so I'm always glad pairing encourages this conversation.

Pair programming doesn't encourage quiet reflection and exploration. You can't just sit back and read some code. You can't just sit and think. I mean, you can, but then your pair is just sitting there.

This is a bit of a double edged sword – pair programming does encourage us to get things done but it's also true that sometimes we need to get the whiteboard out.

Often just sketching out the problem on a piece of paper to check your understanding is enough to trigger a conversation which might result in a better solution.

It does tend to need one person to drive this process though. I haven't seen it just happen organically.

We rarely pair 100% of the time so there are often times when you get a bit of time to play around a bit with the code and see whether specific approaches would work out and I often use this time for reflection and exploration.

One thing which a couple of the commenters on the original blog suggested is that perhaps more rotation was needed to help overcome some of the problems and from my experience it's vital that we do rotate otherwise the pair will end up hating each other!

I recently worked on a story with 3 other people across its life and each person pointed out something that I hadn't previously considered and which led to an eventual output that was much better than it would have been otherwise.

I think rotating different people onto a story can help lead to more innovative design as long as we have people working together who are relatively flexible and open to trying out new ideas.

Mark's post is certainly interesting though and helps identify some of the things we need to be aware of when pair programming – we don't just want to follow the practice blindly.

I came across a couple of quite interesting blog posts recently which described some approaches to interviewing which suggest a more empirical approach to interviewing whereby the interview is treated more like an audition for the person being interviewed.

I like this idea and it's something that we do when recruiting developers in a pair programming interview.

The general idea is that we pair with the candidate as they go through a coding problem. It's perhaps a little different from a normal pairing session in that the interviewee is more than likely driving for the majority of the session.

Sometimes we might also have another interviewer observing the pairing session and giving input where necessary.

While many people may not have specifically pair programmed before nearly everyone has worked with someone else at one computer on a problem so I haven't ever found that a candidate finds it too much of a leap because they're used to working alone.

One of the really cool things about a pair programming interview is that it's much closer to what a real situation on a project would be like which I think helps you to gain a more accurate picture of the skill level and potential of the interviewee.

As an interviewer you get the chance to see how quickly the interviewee will pick up new ideas, to an extent how well they work with other people and first hand experience of their level of expertise when it comes to coding.

From my experience of other types of interviews it can be quite difficult to tell exactly how much knowledge someone has in a specific topic but in a pair programming you can just see for yourself so it works out quite well in that sense.

It's certainly not fool proof and I quite like the way that Hash Rocket have taken this idea to the next level and get people to come there and pair program with them for a week before they get hired.

This seems like the next logical step and I guess if you have the ability to do this and candidates are prepared to give up their time then it's a really useful approach.

As Knut Haugen points out, the interview process is as much an opportunity for the employee to work out if they actually want to work for the potential employer and I think having the opportunity to pair with some of the people who work there is a great chance to assess this.

Dave Nicolette suggests that the pairing part of the interview process is considered the only meaningful part of the interview process in the team he's coaching and while I'm not I'd go that far I do think it's a very valuable approach and one I'd recommend even if you don't pair program all the time on your team.

Dan North has been presenting his 'Pimp my architecture' talk again at QCon San Francisco this week and after reading the hugely positive feedback on Twitter I decided to watch some of it again.

The idea of getting people to help each other rather than pair program is what stood out for me this time, something which Brian Guthrie also pointed out:

"We didn't do pairing, we did 'helping'. You can't get alpha progs to 'pair' but they'll tell you what they know."

It's been quite common at the places that I've worked at for pair programming to be frowned upon and sometimes that's not the most important battle to fight so the team will be more selective about its use.

I was discussing this with some colleagues this week and it does seem that pair programming is a trigger word/phrase with negative connotations for productivity.

On the other hand, something which is rarely frowned upon is having a team 'working collaboratively' and in fact most of the time this is considered a very good thing.

When we work alone I still find myself calling a colleague over to help me out when I get stuck and while I could probably work something out alone given enough time I don't think that approach makes sense when working on it with someone else leads to us solving the problem much more quickly.

Josh Bloch speaks along similar lines in the interview with him in Coders at Work:

I don't like working in total isolation. When I'm writing a program and I come to a tricky design decision, I just have to bounce it off someone else. At every place I've worked, I've had one or more colleagues I could bounce ideas off of. That's critically important for me; I need that feedback.
…
I've known people who don't feel this way – who are willing to program in a vacuum. I think it hurts them.

I think it's fairly inevitable that if a team is to deliver software effectively then there are going to be times when people are working together to solve problems.

What we choose to call that can be varied depending on the context we find ourself in.

A colleague and I were working on some code a couple of weeks ago which mostly revolved around investigating the C# reflection API to work out which methods we needed to use.

My colleague was driving while we were doing this and our progress seemed very much based on intuition about the API rather than being gradual.

In fact it was quite similar to one of the situations in which Uncle Bob suggests TDD doesn't work so well:

…
I need the freedom to fiddle around with the formatting and the structure until everything is just the way I want it. Trying to do that fiddling with TDD is futile. Once I have the page the way I like it, then I’ll write some tests that make sure the templates work as written.

My colleague was fiddling around with the code trying to work out what combination of methods we needed to call and I was struggling a bit to get involved through no fault of my colleague.

He was describing what he was doing but for a lot of the time what we tried didn't work and then suddenly it worked.

It all seemed a bit magical to me!

At this stage we decided to refactor the code and thought that it would might be useful for me to do that refactoring so that I could explain my understanding of the code my colleague had just written and see if I had followed what he'd been doing.

I was able to extract out methods correctly most of the time but there were a couple of places where I hadn't quite understood what was happening so this approach allowed my colleague to explain it to me.

My initial thinking when we started doing this coding was that perhaps it wasn't suitable for pairing because it's quite exploratory but it seemed to work out reasonably well and my understanding of reflection is now slightly better thanks to my colleague's explanations.

I've been pairing a bit more regularly recently after more sporadic pairing sessions over the last 9 or 10 months and I've noticed that I've picked up some habits which aren't really that effective when pairing so I'm on a mission to sort that out.

Moving around the code too quickly

One thing that I often forget is that when you're driving you know exactly where you're going with the mouse or keyboard just before you do it whereas the other person doesn't know until you've done it.

As a result of this it is useful to commentate on what you're about to do and not move around the code at break neck speed, but instead take your time and pause after each step to allow your pair to follow where you are in the code.

It seems like this might slow you down but I find that quite frequently when I race around the code in this way I'm making assumptions about the code and I didn't even know that I was doing it.

Having someone else working alongside you forces those assumptions out into the open and it's amazing how often you end up going a different way than you had originally assumed.

Moving through the code more slowly is especially important if you call someone over to help you with something since in this situation they have very little idea about what you're doing so they won't be able to provide much assistance unless you take the time to provide the context to them.

Not listening to other solutions

Another trap which is best to avoid is always thinking that you personally have the solution to all the problems the pair encounters and that your solution should always be the one used.

I think this becomes a particularly easy trap to fall into when you've learnt a few ways to solve problems and the temptation is to always use these solutions and block out suggestions which we judge as being inferior to our solution.

This seems similar to Jay Fields' post 'Kill your darlings' where he describes a technique George Malamidis taught him:

George Malamidis taught me something about code attachment a few years ago: You always gain by allowing someone to show you an alternative solution. If someone wants to solve a problem in a different way, there are several gains to be had. If their way is inferior, you have an opportunity to mentor a team-mate. If their way is equally elegant, you've gained another solution, or point of view that may be superior in the future. If their way is superior you learn something new and the codebase improves. In exchange for these gains you only need to give up time. Time is valuable, but it's also well spent on improving the ability of a team-mate or your personal ability.

I noticed that when working with my colleague Lu Ning I wasn't very keen to understand his ideas about how to structure code and move data between the client and server sides because I was convinced that the way I already knew would work better.

As it turned out when I eventually started listening I realised that his approach worked much better than any ideas I had so he taught me something new.

This situation comes up a lot when pair programming and I think it's useful to always keep an open mind – that way you might learn something you didn't expect to.

Grabbing the keyboard away

I think this one is more obviously ineffective and I don't think I do this as often.

I did suggest in another post that getting control of the keyboard can be a useful way to help you become more engaged in a pairing session, it's certainly useful to ensure that you communicate why you're doing that and checking if it's ok with your pair if you drive now.

On the other hand just grabbing the keyboard and typing without saying anything because you think you have a 'great idea' is not really an effective way of working together with your pair as it effectively sidelines them.

In Summary

These are just a few observations of some things I've noticed and as always there are no doubt more ways that we can pair program ineffectively.

Pair programming for me is not just about putting two people together and having them work the same way they would normally – there certainly seems to be a completely different dynamic to the way we work and I think it's important to adjust the way we work to adapt to that.

I've written a few times previously about pair programming and how I think it's one of the best practices I've seen used on agile teams but in order to ensure that we're making the best use of this practice it's important to ensure that both people are engaged.

It is often quite difficult to persuade people who aren't used to extreme programming that having two people working at the same machine is actually beneficial and this task can be made even more difficult if one person is losing focus or interest and therefore isn't actually adding much value in that pairing session.

Who's responsible for making the pair function well?

In all likelihood the person who's not currently at the keyboard is going to be the one losing focus and in this situation I often wonder whose responsibility it is for ensuring that the pair is functioning well.

My initial thinking is that it's the responsibility of the person driving to bring the navigator along with them and that if this isn't happening then they're not doing a very good job in the driving role.

A fairly typical scenario is for the driver to be coding and not really saying anything to their partner while they're doing so, therefore internalising all the mini decisions that they're making.

Vocalise your thoughts when driving

When I was first shown how to pair program we were taught to vocalise everything we were doing while at the keyboard, thereby pretty much providing a running commentary for our pair to allow them to follow what we were doing.

This commentary could be anything from detailing a refactoring that we've seen and want to perform to asking our pair for help to understand a bit of code that we're finding tricky.

Hopefully this commentary helps create an almost constant conversation between the two people pairing.

Regaining focus

If the driver isn't providing this commentary then an idea which Dan North suggested to me is that the navigator can try and get this conversation going by commentating on what their pair is doing or by asking them questions.

I suppose done to an extreme this might be a bit annoying but it should only be necessary to do this for a short amount of time until the driver starts being more communicative and I've found that it works quite well as a technique for getting yourself engaged again.

Another approach is to get back control (with your pair's permission!) of the keyboard and continue where your pair left off until you have regained the context that you previously lost at which stage you might hand the keyboard back.

It might also make sense to take a break for a few minutes and walk around or get a drink before returning to the pair – I find that this works well for me too.

Doing something is better than doing nothing

The key here is that once we identify the problem the worst thing that we can do is to do nothing. The current situation clearly isn't working for us so we need to do something about it.

As I learnt when studying NLP:

If what you're doing isn't working, try something else, anything else, regardless of whether what you had been doing should have worked.

While discussing some of this ideas with my colleague Lu Ning he suggested that if we are losing focus then it might be an indicator that we should split up the pair.

I think we should still look to try some of the above ideas but if they don't have any effect then Lu is probably correct.

I've worked on several software development teams over the last few years – some that pair programmed all the time and some that didn't – and one of the key things that I've noticed is that the level of collaboration on these teams was significantly higher when pair programming was being done on a regular basis.

The following are some of the observations I have noticed in teams which don't pair program frequently.

A culture of silence

The amount of communication in a team which doesn't pair is almost by that very definition going to be lower than in one that does – you don't have that almost constant dialogue/discussion going on that you get when a pair are at the keyboard since everyone is head down coding in their own little world.

A consequence of this is that other types of communication are also reduced.

When a room is full of people pairing it's not uncommon for someone to shout across the room for a colleague to come and help them and their pair with something. Since there is already a lot of communication going on this doesn't feel that unusual and since other people in the room might hear us speaking we can also get the benefits of osmotic communication.

When we don't have that it feels very awkward to do this and in fact often the person you call won't actually hear you since their head is down and focused on the task their working on.

The inclination the next time you need help is to just work it out yourself, further harming team collaboration.

Code silos

Another consequence of having people working alone is that people become very specialised in certain areas of the code base and then when they either leave the project or are ill there isn't anyone else who knows their area to work in that area of the code.

It becomes obvious that we have silos in the code base when code starts to be referred to as "X's code' or 'X's way of doing things". Another danger sign is when there is a lot of talk about "handovers" – a sure sign that collaboration hasn't been taking place.

One way to address this problem without pair programming is to mandate that code reviews must be done before code written alone is checked into the source control system.

The problem with this is that there isn't really way to enforce it if people don't want to have their code looked at by someone else beyond reverting their changes which seems perhaps over confrontational.

Repeated code

The tendency to end up with several people solving the same problem is one that rears itself quite frequently when people are working alone.

Since each developer doesn't have as much visibility into what their colleagues have been working on – the sharing of knowledge that pair programming encourages is absent – we often end up with several sub par solutions to the same problem instead of collaborating to come up with one good solution.

Repeated code is perhaps the biggest waste of any developer's time – we are adding no value at all by doing it and are creating confusion for our colleagues as they now don't know which bit of code is the correct one to use.

In Summary

I'm sure there are ways to overcome these problems but I've never seen it done effectively without having people working together more closely.

I'd be interested in hearing ways that others have created collaborative teams without having developers collaborating closely by using a practice such as pair programming.

One area of development where I have sometimes wondered about the value that we can get from pair programming is when we're spending time doing some major refactoring of our code base.

The reason I felt that pairing on big refactoring tasks might be difficult compared to when working on a story together is that with a story there tends to be a more defined goal and the business have defined that goal whereas with a refactoring task that goal is often less clear and people have much wider ranging differing opinions about the approach that should be taken.

Having spent time pairing on some refactoring work for most of the last week I have changed my mind and I think that pairing on refactoring tasks is actually extremely valuable – certainly equally as valuable as pairing on story work and perhaps more so.

What I noticed in my time pairing on this task is that actually although there is more conflict over the approach that should be taken this actually works out reasonably well in terms of driving an approach that is somewhere between pragmatic and dogmatic.

From my experience, the mentality when you're the driver in a refactoring session is pretty much to want to fix everything that you come across but having someone else alongside you helps to rein in this desire and focus on making the fixes that add value to the code right now.

I was quite surprised to notice that within just one keyboard switch we had both suggested to the other that making a particular refactoring should probably be added to our 'refactoring list' to have a look at later on rather than looking at it now and potentially getting into a yak shaving situation.

Another thing I noticed was that the navigator was often able to point out things that the other person didn't see – sometimes making a certain change to the code had a bigger impact than the driver had expected and the navigator was able to spot this quickly and initiate a discussion about what the next step should be before we had gone too far down the wrong path.

Refactoring code effectively and not making mistakes when doing so is one of the more difficult skills to learn as a developer and I think it is very difficult to learn by just working on your own since the approach to effectively refactor code by taking very small steps is not necessarily obvious.

While there are certainly books which explain how to do refactorings on our code a lot of the approaches that I like to use have been taught to me by more experienced people that I've had the chance to pair with. Pairing creates the opportunity for these skills to be passed on to other members of the team.

My colleague Nick Carroll recently blogged some ideas about what to do if your pair is hogging the keyboard, suggesting using a timer which keeps track of how long each person has had at the keyboard as a useful way of ensuring that both people in the pair stay more engaged.

While I can see the thinking behind this I think it is addressing the wrong problem.

From my experience we don't always want to be moving the keyboard between the two people quickly at all times – I have certainly seen times where it makes sense for one person to be spending more time at the keyboard than the other.

A particular example of this is when there is a difference in experience between the two people at the particular skills required to complete the task they're working on.

On a project I worked on around 18 months ago I was struggling to stay engaged as the navigator as I didn't really understand what was going on and the half/half split in keyboard time wasn't really helping.

Chatting with a more experienced colleague about this at the time he suggested that when I paired with him he was perfectly happy to spend the majority of the time navigating while I drove so that I could get more understanding around the code base and become more useful to the team.

This colleague was clearly keeping the big picture in mind and I haven't come across a situation since then where someone acted so selflessly for the benefit of the team.

The lesson for me from this situation is that sometimes it makes sense for the person who can gain most from driving to do so more frequently.

The other thing I think Nick's post is suggesting is that the only way for you to be engaged in a pair is when you are at the keyboard, which I don't believe to be correct.

The role of the navigator shouldn't be underestimated as when it's done well it provides a very good complement to the person driving as that person is taking a bigger picture view of what the pair are working on and ensuring that the code being written is still fitting in with the rest of the system. Dahlia has written an informative post about some of the things that she does when navigating in a pair.

Another idea Dan suggested to me is to commentate on what you think is happening/what the other person is doing at the keyboard when you're navigating and feeling a bit lost.

I've spent quite a bit of time working with Lu Ning on some Javascript on our project recently and have been trying out this approach there and I think it's helped me to understand things better although clearly it takes a lot of patience from the driver if you take this approach.

I've been having a bit of a discussion recently with some of my colleagues about what we should do when pair programming and one of the people in the pair has to step away to go and help someone else or to take part in an estimation session or whatever it happens to be.

If we're pairing in an effective way then it should be possible for the person still at the computer to keep on going on the story/task that the pair were working on alone. Obviously sometimes that isn't the case especially if one person has been driving for the majority of the time but for this post we'll assume that both people are capable of continuing alone.

Continuing alone doesn't necessarily mean that you become the code fairy, which is where one of the people in a pair goes and implements the functionality of something they had been pairing on in their own favoured style.

My initial thought is that if the absence is only short term then you shouldn't plow on too much otherwise you need to spend time bringing them back on the same page when they return.

To give an example, a couple of weeks ago I was pairing with a colleague and we were retrieving a value from a Dictionary if it existed and creating a value in the Dictionary if it did not exist.

Dave had recently shown me quite a clean way of doing this which I wanted to discuss with my colleague in case they hadn't seen it before – the approach we had been taking to solve this problem wasn't along these lines before my pair was called away.

public class DictionaryExample
{
    private readonly Dictionary<string, string> values = new Dictionary<string, string>();
 
    public string FindValue(string key)
    {
        if(!values.ContainsKey(key))
        {
            values[key] = "somethingNew";
        }
        return values[key];
    }
}

When he came back I suggested this approach and he was happy to go with it.

I sometimes write down stuff I'm unsure of when pairing and I find that if my pair goes off for a short amount of time then this can be a useful time to look that up.

If we decide to keep on going during their absence then I think it's important that we keep going down the same path that we were when we were pairing to reduce the amount of catching up our pair needs to do when they return.

If they have gone away for a longer period of time then we should treat it as them having left the pair and we can look for someone else to pair with or just code as if we were working alone.

That's my current thinking on this – some colleagues have suggested they think it's better if we just keep on coding regardless but I think this approach finds a happy medium.