Two heads are better than one - pair programming and beyond

2016-06-30

Pair programming isn't really a controversial topic any longer. The real cool kids are even talking about mob and full team programming. However, I wanted to talk about this to lead into a more general post on the social aspects of programming at a later date, so here we go!

To me, paired programming is a tool in the toolbox - it isn't something that I do every day, it is a situational option, but one I've used when necessary or convenient for the past 15 years. Times I think it is really handy are for mentoring or when the problem is difficult and the solution is either unknown or sketchy. Let me talk about each in turn.

First of all, for mentoring - I think this is a mentoring style that is really tough to beat. Yes, it means that the experienced programmer is really committed to doing that mentoring, but that's what a mentor is for - if you aren't providing that focussed attention and teaching for at least some of the time, you aren't really mentoring. When using paired programming for mentoring, the learning programmer should always be the one at the controls. The mentor needs to grab a tea, relax, and adopt a teaching, patient state of mind. There's a lot of things that will get missed if the mentor is controlling - all the tricks that someone who has been living and breathing in an environment for years does without thought - the IDE shortcuts, the debugging methods, the library routines - those are all better learned through doing.

I'll write a whole blog at some point on mentoring - but for now, just remember that when you're mentoring, you are supposed to guide the person you are mentoring to find the answers and solutions, not just provide it for them.

The second place paired programming works are those difficult problems where the solution isn't fully defined. If you know exactly what you are doing, what the plan is, it probably isn't worth it. It is when you are a bit in the dark, where there's some direction but no lit path, that's where paired programming comes into its own. I should mention here that I've also done this with a trio, and that seems to work fine too. I've never tried the full team mobbing of one problem - I read an interesting article on it, but it is a significant rethinking of team dynamics and my current team projects haven't really been appropriate to giving it a try - and I'm honestly not sold on it as a concept anyways. But maybe one day, but till then, paired programming to tackle those meaty problems remains an excellent technique.

When two (or more) experienced programmers sit down to pair program, it matters a lot less who is at the keyboard. That decision comes down to preference - maybe there's one person who really wants to be at the controls and the other doesn't care. Maybe they switch off. All that matters is that everyone is happy, that everyone is cool. Everyone needs to play nicely together - compatibility does matter. There are many styles of programming and I think to pair program effectively, you need to have compatible styles. You need to be able to follow what the other person is doing or thinking. I've had a few teammates who were excellent programmers, but who I found it more difficult to pair program with. On the other hand, I've had some pair programming partners where we were in incredible sync that we were just tearing through some serious problems.

I find those times really fun - though quite tiring. Paired programming not only is efficient, it is also very focussed - email tends to get ignored until the task is done, people who swing by your cube and see two people tend to come back later. It means a very intense programming session, especially when things go well. That's pretty awesome and a great way to deal with heavy problems.

I don't, however, think pair programming is something that can be really mandated - there is too much need for chemistry and compatability in the pairs. I think it should be encouraged (or certainly not DIScouraged, which I've heard about happening), but programmers work in different styles and different ways and people shoudl do whatever makes them most productive.

I'll go on in my next blog to talk about my belief that programming is a social work, not a solitary one, for anything bigger than a breadbox. Till then, if you haven't tried pair programming, give it a shot. If you have, feel free to let me know what you do differently.

-cdr