Motivation
Let's be honest. Over engineered solutions are strangely attractive. We developers are drawn into it like bugs into a bugzapper. We end up spending way too much time on things we don't even need. That's just wrong. We need somebody to get us back on track. And that's exactly what pair programming is going to give you.
When you pair, one person codes---the driver. The other person is the navigator, whose job is to think. As navigator, sometimes you think about what the driver is typing. (Don't rush to point out missing semicolons, though. That's annoying.) Sometimes you think about what tasks to work on next and sometimes you think about how your work best fits into the overall design. This arrangement leaves the driver free to work on the tactical challenges of creating rigorous, syntactically correct code without worrying about the big picture, and it gives the navigator the opportunity to consider strategic issues without being distracted by the details of coding. Together, the driver and navigator create higher-quality work more quickly than either could produce on their own.1
Applicability
Okay, there might be a few situations when you need some time alone. But, really, in all other cases, pair programming is applicable. That doesn't mean it's easy though. In fact, for most people, it turns out to be quite painful to say goodbye to their time spent in isolation, as evidenced by the type of response you will get when suggesting pair programming to die-hard alone coders:
- I'm faster on my own
- Can't pair with that colleague, I get nervous
- Pair programming is too tiring
- We've split up the work and we'll get it done faster if we use two keyboards
- There's too much background noise
- I'm just slowing her down
Iwein Fuld wrote a great article on the subject a in 2010, and this is what he said:
Some of this might sound plausible, so let me axe that down first. No you're not faster on your own, you're just creating more crap for your colleagues to puzzle over and eventually delete. The code you write alone sucks. That guy that is getting on your nerves is trying to tell you (clumsily) that your code sucks, try to listen to him and you'll turn into a better programmer. Or maybe you can teach him something and he'll stop getting on your nerves. If your code is so simple that you can split up the work in advance you're writing it on too low an abstraction level, or you need to work on this in two pairs. If you're slowing the other guy down, that's a good thing. That will prevent him from writing code that you cannot maintain. If you don't feel worthy of your colleagues code, get over it, or get off the team.2
In some situations pair programming is not a good fit. Be sure to understand the need for alone time
Application
First of all, you optimize the conditions for pair programming. That could include many things, such as:
- Noise cancellation: if there's too much noise in your environment, if people are bothering you for the wrong things, if there are things that would prevent you from being focused even if you would be working on your own, then you need to fix it.
- Pair programming ergonomics: if you can't pair comfortably, then it's not going to fly. If your navigator is unable to read your screen, then it will fail. Getting another monitor might help. If - in order for the navigator to see the screen - the driver needs to work in a cramped position, it will fail as well. There are certain type of desks that just don't support pair programming at all. Rearrange the office floor to fix it. Make yourself comfortable.
- Pick a style. Iwein lists a number of styles in his article^2^. Pick the right one for the task at hand.
Consequences
Pair programming helps you to stay focused on your task and it grows collective ownership.
References
- James Shore, The Art of Agile Development, 2010, https://jamesshore.com/Agile-Book/pair_programming.html
- Iwein Fuld, Practical Styles of Pair Programming, 2010, https://blog.xebia.com/2010/05/09/practical-styles-of-pair-programming/