Pair programming. Understanding of this topic may vary among the readership.
Some of you might have the vague notion that it means two programmers working together… or something. Others of you might have a more solid grasp of particulars and a vocabulary that includes terms like “driver-navigator” and “expert-novice.” And, a few may even understand the full origin story of pair programming as a core plank of the eXtreme Programming (XP) approach.
Hey, Look, a Pair Programming Reader Question
I’ll soon return to that origin story. But first, let’s look at why I’m talking about this at all. I’m actually gearing up to answer a reader question:
I was interviewed by a company that [does] full pair programming. I hate the idea of spending all my day with somebody looking at me writing code. What do you think about it?
So to clarify a little here, we’re talking about a company that subscribes, full stop, to the XP rule that “all production code is pair programmed.” For all intents and purposes, this means that dev teams pair program 100% of the time as a rule.
Should you take a job at such a company?
It’s honestly hard for me to say for any given person since my advice would be so very tailored to your individual personality and preferences. So rather than immediately give a thumbs up or down, I thought maybe I’d explore the topic of pair programming more broadly.
Since my publication of Developer Hegemony and subsequent departure from a traveling consulting/training life, I’ve made this blog increasingly one about software developer empowerment. Today, I’d like to look at the subject of that pair programming through that relatively uncommon lens.
I want to examine not whether pair programming is a Good Thing (TM), but whether it’s a good thing for you, as a software developer.