Pair Programming: Why?
Banging out code is not what this job is about
I used to think pair programming was bunk. Pair programming, if you’re not familiar, is when two engineers are directly working together on a problem. They could be working on two problems, but instead they’re working on one. The team could be knocking off items on the to-do list, kanban board, etc faster. If you have two engineers, and only one of them is typing, then you’ve really only got one engineer.
These feelings are pretty normal. This is how I used to think. Thinking this way is wrong. Why is it wrong? Because banging out code is not what this job is about.
Maximizing key presses makes sense only under one circumstance: you know precisely what you have to do, for every single thing on your list. It only makes sense when there are zero unknowns. Does that sound like the reality we all live in to you? No, it doesn’t.
Pair programming works because the instant something doesn’t make sense to the other person you’re forced to address it. Immediately stopping is a feature. Why? You’re never going to know more about your code than in-the-moment you’re writing it. That is where you’re going to find and fix the problems in the best way. Not even the following day, week, or month, later when that bug report rolls in, or you realize “I totally did this the wrong way, this is now tech debt, and it needs to change. CRAP.”
Having another person looking at what you’re doing, in-the-moment, is going to surface a lot more problems. Two minds, working together, to create something is fundamentally better than one. It is inherently difficult to vet our own first instincts on how to come to a technical solution. You need someone else to do that with you in order to do it effectively.
