I love pair programming. It’s fun. It’s productive. It helps me grow.

Software development is a collaborative process. We work with stakeholders to develop requirements. We work in teams to design architecture and plan stories. We review each other’s work. We review delivered features with stakeholders.

Most tasks require communication and collaboration. However, one task is often a solo effort: coding. There’s nothing inherently wrong with programming alone. But when we program solo, all the time, we miss an opportunity to grow as engineers.

Learning to golf

Brett loves to play golf. He gets 18 holes in every day and dutifully tracks his score. Brett always plays alone. He measures his progress with his daily scorecard. Of course he isn’t alone in his quest to improve. Sometimes he does an online search for tips to improve his game. Occasionally, he phones a friend to discuss his progress.

Tory also loves golf. She’s on the course daily with a group of friends. She tracks here scores over time and looks for online tips. She also gets continuous feedback from her golf buddies while she plays. They might suggest that she change her stance, grip, or swing. Maybe she should consider a different club. She also observes her friends and provides them feedback. That feedback might be to suggest a change or to keep doing something that works; something she can incorporate into her own game.

Bett and Tory both know their daily scores. They can both describe the final output of their games. This ball went too far, this ball drifted left, this ball was short. They make adjustments based on the data. They change their aim or how hard they swing. But that doesn’t help them choose which club to use or how to adjust their overall form.

Tory gets feedback on her swing based on her swing. Her friends see her play and give encouragement and suggestions based on how she plays. Brett gets feedback on his swing based on how he perceives his swing. His friends have never seen him play. They only hear Brett describe his game. If Brett uses a mop instead of an 8 iron, he won’t get feedback unless he mentions the mop. If Tory grabs a mop from her golf bag, she gets feedback before she has a chance to swing.

It’s obvious that Tory will learn more quickly and become a better golfer than Brett.

The problem with only solo programming

When we code solo, we get feedback. During code review, our peers make suggestions to improve our code. That helps us grow. But it isn’t optimal because we only get feedback on what we coded, not how we coded. We learn faster when we get immediate feedback on our swing and not just on the final scorecard.

In retrospect, this is obvious. Initially, it wasn’t obvious to me. I started pair programming to drive quality and timeline improvements. I didn’t start pair programming to improve my skills. My “aha!” moment came from a junior engineer. He told me that programming on our team was intimidating. He saw concise, effective code in merge requests from senior engineers and didn’t know how he would keep up. He thought they knew the end-solution before they started typing. When would the “senior solution” just come to him?

After pairing with multiple senior engineers, he discovered that senior developers don’t begin with the finished code in mind. It’s an iterative process. As they solve the problem, they better understand the problem and the solution. They refactor the code over-and-over until it becomes the concise, effective solution that they submit for code review. Senior engineers aren’t better at magically seeing solutions in code. They are better at iterating toward solutions. They had a process that he could adopt. Writing code like a senior engineer became an acheivable goal because he had experienced how senior engineers develop, not just what they develop.

That was my lightbulb moment. The power of pair programming for professional development is that it draws the curtain back on how. We get better at programming by receiving feedback from others about how we program and from observing how others program.

You can learn from everyone

Don’t worry about the skill level of your partner. People of all skill levels have something to teach to and learn from each other.

It’s easy to see that a less experienced engineer will learn from a more experienced one. Engineers of similar experience have a lot to gain from one another too. Even if two people know the same amount of stuff, they’re expertise lies in different topics. Pairing is an opportunity to exchange knowledge.

What’s less obvious is that senior engineers learn from junior ones. This is especially elusive to junior engineers. I have had young developers express concern that they are “slowing me down” or “wasting my time” when we pair. I remember being a newly-minted engineer and can relate. That fear is misplaced. Don’t let it stop you from pairing with someone with more experience. They will learn from you too.

When I pair with junior engineers, I see the world through their eyes. I see a new perspective that I would otherwise miss out on. I have to explain my ideas to another person. They could be general software development principles or specific to the project. Working through those ideas helps me better understand them.

I also find that junior engineers have learned their trade in a more “modern” development landscape. They help me stay current.

It’s also fulfilling to impart knowledge. I hope the juniors I work with will find greater success than I have. I hope I helped tham by sharing my hard-earned knowledge early in their careers. Seeing them succeed long after the pairing session has ended is deeply rewarding.

I don’t worry about pairing with engineers of the “correct” skill level. My goal is to pair with as many engineers as I can. I can learn something different from each of them. And I hope they learn something new from me too.

Start pairing

I’m proud of the skills I have today, but I’m not satisfied. I want to build something cool today, and something cooler tomorrow. I want to push my abilities and my skillset. Pair programming is part of my regimen. I still solo program and I still learn in other ways. Pair programming turbocharges my growth by giving me new insights into how to program, not just what to program.

I don’t want to golf with a bag full of mops.