When you hear the term pair programming, what thoughts come to mind? As a programmer, are you concerned that you won’t be able to concentrate? As a manager, does pair programming conjure up thoughts of paying two people to perform one job?
I certainly understand that knowledge workers such as programmers need concentration time. I just don’t believe (any more) that programming should be considered to be a solitary activity. Sure, we all need time to gets things clear in our own heads, and sometimes the best way to accomplish this is with a little quiet time. There are other times, however, when it is faster more productive to work with others.
I’m sure that you’ve had the same experience that I’ve had in working through a difficult problem, where the ability to talk through a problem with someone else, to share perspectives and bounce ideas off of one another yielded a much better outcome. And there are those times when the act of verbalizing a problem is all that you need to generate that little spark of insight. All in all, I’ve had plenty of times where I’ve been grateful that others were willing to collaborate with me in dealing with complex problems.
And that is what pair programming brings to the table. And it’s also why a manager shouldn’t walk around worried that he or she is losing productivity because programmers – or testers automating test code – are paired up. Knowledge workers aren’t a part of a typing pool. They are engaging their collective intellect on solving difficult problems.