April 11, 2024
I typically pair with people on my team but I recently reached out to Joe Tannenbaum when he mentioned that he'd never paired before. We both took a chance on an internet stranger, hopped on a Zoom call, and had a blast pairing together! It turned out to be a great way to connect with another developer and turn an internet acquaintance into a real friendship.
That sparked the idea: what if I tried pairing with complete strangers on the internet? I put my calendar link on Twitter and got dozens of pairing appointments. It's been a huge success - I've had a chance to meet and code with a wide variety of people from around the world on a bunch of unique projects and stacks.
Joe coined the "Pair-amid Scheme" and I'm encouraging every schemer to pair with others and turn this into something bigger. My favorite mention on Twitter is someone saying they paired with someone - it's like watching your kids grow up. I'm a proud pairing dad, I guess! So if you're game, reach out to a Twitter mutual, old colleague, or total stranger and see if they'd be down to pair for a hour. I think you'll love it!
I've been pair programming for a long while let me tell you, my pairing sessions are the highlight of my work week. I pair several times a week, typically for 90-120 minutes at a time, and I find the benefits are well worth the time investment. At this point I've spent thousands of hours pairing and I hope to influence you to give it a shot!
There are many styles of pairing, but here's mine: we typically chat a bit, catch up if needed, and then take a couple minutes to create a menu of possible pairing tasks. These tasks are just what's on your plate at the moment - nothing exotic, not meant to impress, but just day to day coding work. After we lay out all of the possibilities we pick the one that will be most interesting or useful, and hop right in. I try to pick things that I know I could use a second opinion on, or that would be fun to share with another developer. If possible, I avoid tedious or mindless work that doesn't really need discussion or thought.
One person starts "driving" - sharing their screen and do the bulk of the work. I find that most of the time is spent talking, not typing - discussing solutions and exploring ideas together. We work the first task to completion, then switch drivers and move on to the next task. In a typical pairing session I expect to tackle 1-3 different tasks depending on complexity.
One mistake I've made is to start a big refactor in a pairing session, only to run out of time and leave the driver with a mess to clean up after the session ends. I've learned to pick smaller tasks that can be completed in the session. That doesn't mean you can't work on big work - just pick achievable milestones within that larger scope.
My solutions are always transformed during a pairing session. I come in with an idea of how I want to solve a problem, and leave with a new twist or a completely different implementation. Talking to another developer is the ultimate rubber ducking experience.
I love to teach and be taught - a pairing session is the perfect time to learn something practical. I often pick up language tips, tooling, and resources.
Pairing makes code review smoother in a couple of ways. First, since you helped write the code, you are very familiar with the following PR. And if you have a lot of questions about a gnarly PR, pairing is a great time to talk through what the other developer was thinking when they wrote it.
Finally, it's just fun. Even the most introverted developer needs to connect with others, and pairing is a great way to bond with your colleagues.