It took me a long time to understand the joys of pair programming.
When I took my first computer programming class in the 1990s, computers were a limited resource. The newer, better computers were used by two people together. I took a significantly older, slower machine so that I could go at the speed of my own thoughts. A computer twice as slow seemed far faster than working with another person.
That was a long time ago, and today I can’t imagine not having the joys of pair programming.
Coding at the speed of my thoughts was informative for learning a new language, but on my best pairing days I can run at the speed of imagination. Pairing lets me tackle a hard idea and run straight to the solution. My pair and I are in constant collaborative motion, adeptly dodging a rathole or fluidly smoothing out a stuttering idea. I still like soloing when I’m learning mechanics and syntax in a new language or framework. But pairing is what I turn to when I want to build, to design, to explore better use patterns.
A few months back, Betsy Haibel and I were building a brand new app together. How should this new app interface with the legacy system’s users? What relationships should the models have with each other? Pairing and talking through these design problems helped us uncover areas that could have been easily overlooked – and figure out the best way back out when we ran into problems.
Have you ever had the experience where you pushed up an overly large pull request? and then had insightful feedback on a critical part of your changes that required a thorough redesign? When that’s happened to me, I wished I could have gotten that crucial five seconds of knowledge drop before I’d built the rest of my changes around wrong assumptions. The pain you experience in this situation is the pain of not pairing.
Pair programming helps developers sustain coding at their best and brightest moments. But the benefits don’t stop there!
A few weeks ago, a client was showing me a file on GitHub. After he’d navigated into the second of many nested subfolders, I suggested, “use T”. When you’re in GitHub’s codebase view, hitting “T” on your keyboard opens up a quick-navigate feature that lets you partially type a filename or extension and use “Enter” to pull up the file. It’s nearly impossible to discover this feature on your own – who would look at a webpage and think “is there a keyboard shortcut for file navigation?”?
Another reason I love pair programming is how it dramatically accelerates tool familiarity. I’m able to quickly learn new ways to use tools that would’ve taken me hours of reading a user manual to uncover – assuming such a user manual even exists.
A few years ago, I started a new job and started using a new code editor. The person onboarding me pointed out a word on the screen that we wanted to find and replace, and suddenly every instance of the word in the file was highlighted and ready for mass-editing. “How did you do that??” “Ctrl-D” Why would anyone look at a text file and think “is there a way to visually find-and-replace, but better?” I never would have! But my pair-partner did and now I use (and share the joy of) Ctrl-D all the time!
Earlier this week, I joined Zee Spencer in our live-streamed co-learning series, Debugging Downtime. Many years ago, I happened to get a glimpse into my manager’s problem-solving process as he was diving into a production problem. “Next time that happens, can I join you so I can learn about this?” I asked. A time or two later, and I’d learned enough about what kinds of questions you can ask yourself to create hypotheses around production problems. It’s hard to teach suspicion outside of a pairing environment.
Pairing helps distribute knowledge that can’t be easily obtained. Sometimes that’s practical, hands-on problem-solving that makes sense when you work on a problem together. Sometimes it’s an internal software ecosystem that isn’t documented internally and has no external users. Pairing helps me get to that hard-to-obtain knowledge, and can be a part of your plan to reduce the pains and dangers of your team’s knowledge silos.
I love pairing because it helps me be my best imaginable self. Sometimes that’s patching in a personal gap in knowledge, and sometimes it’s the encouragement that comes from validating that the problem we’re facing really is hard. The memories that stand out to me over the years are not from striving solo in the dark, but of facing the big bad problems together with a pairing buddy.
Roses are red
This expression is true:
Pairing brings out our best
Which is why I like to pair program with you <3
