Pair Programming

Pair programming (and its cousin, mob programming) is a practice near and dear to my heart.

In my work at VMware Pivotal Labs, I pair program 8 hours a day, 5 days a week. I can estimate I’ve spent about 7,400 hours pair programming in total. Some with people who had spent more than 30,000 hours pairing, and some with people who had never paired before in their life. Also with people who were brand-new to some aspects of coding, and with people far more knowledgeable and senior than myself. And I’ve learned a lot from it.

Some people critique pair programming with a “paying two people to do one person’s job” and “half as fast” tack. My response to that is - my job is often not to input code into a computer. If it was, I’d probably be replaced by a robot by now. Engineers are needed to think through problems and design systems. And with that in mind, a pair of engineers will always come up with a better solution than one alone, because the sum total value of two people bouncing ideas off each other will be better than even the sum of its parts.

A few odes to why I love it:

• Sharing context and preventing knowledge silos.
• I’ve never learned faster than when I get to sit down next to someone experienced and work with them and pick up everything I can while asking as many questions as I can.
• I get to teach people things that I’ve previously learned, and through that I actually reinforce and strengthen the learning for myself.
• Getting the chance to dive deep into understanding someone else’s thought process and how they approach problems differently from me, and both of us growing from that exchange of approach.
• Getting the chance to be challenged on my preconceived notions, and asked to back up my opinions. It gives me chances to articulate what I believe, and question myself.
• It fosters a growth mindset.