At Atomic, we program in pairs a lot. It’s how we teach each other and learn from one another. Pairing is how we build confidence that we’re building something actually great, not just something that makes sense to me when I’m under-caffeinated. It’s also core to the way that we run our business. We like the concept so much that, when our founding CEO hung up his keyboard, his successor was a pair of CEOs.
🙈 Pair programming can be terrifying.
If you’re new to programming, new to a language, or just new to a project, pair programming can be brutally intimidating. That’s especially true if you’re just starting your career and you want to make a good impression. It’s even worse if you’re a consultant who bills hourly, and you start adding up how much someone is paying for the hour you spent staring at a function definition, unsure what to do next.
When you’re the least experienced person on your team, you may have to think through a complicated problem in front of someone more experienced than you are. It’s easy to feel a bit superfluous and discouraged. Your brain spends a lot of its time monitoring your more experienced partner for clues that they know you have no idea what you’re doing (even when you do).
Brains are jerks like that. In addition to being very bad at confusing “experienced programming partner” with “Bengal tiger that is probably about to eat me,” they’re also super bad at assessing how valuable you are to a team.
Here’s why you, at your current level of experience, are one of your team’s biggest assets.
🐢 You’re slower (and that’s great).
Going fast only matters if you’re headed in the right direction.
When you and your partner are thinking through a problem, it can be tempting to start coding the moment you chance upon an idea that you kinda know how to build. Brains really like to do stuff that they already know how to do.
Your partner, having been around a lot longer than you, is going to have done a lot more things than you. So their brain is primed with way more shortcuts. Sometimes, those shortcuts are useful and apply to the problem that you’re solving. But sometimes they’re just shortcuts to nowhere.
When you see your partner get all excited about the idea that just sparked in their head, pause. This isn’t bad or a ding on your reputation when you don’t immediately leap to the same conclusion. It’s good that you don’t leap to the same conclusion.
It’s awesome when you say things like, “I’m missing a step somewhere. Could you walk me through what you’re thinking?” or “I don’t see how you got there.” Doing that gives you both a chance to think through the strategy more carefully and thoroughly.
🤷 You don’t know what’s impossible or why (also great).
In theory, theory and practice are the same. In practice… not so much.
Your partner knows a lot about which things seem like they would be easy to code, but are painful and tedious when you actually start typing. Or at least, they know which things were painful a while back, last time they looked it up.
Here again, brains are tricky. They aren’t so good at remembering that what used to be hard to do in Rails 3 might be easier and cheaper in Rails 6. Know who can help cut through that noise? You. The beginner, the newb, the greenhorn.
I love, love, love it when a less experienced programming partner asks me, “Why don’t we just…?” That’s because it’s a great opportunity for both of us. I get to refresh my knowledge so it’s more up-to-date. On the flip side, they get to see how somebody with a few years of experience does that.
Say my memory is accurate, and the thing we were about to do is actually still a good idea. Then we get to talk about how one goes about deciding whether something is still a good idea. I get to show off my Googling skills a little bit, and they learn a bit about programmer epistemology.
Even better, if the world has moved on since I last looked at it, then we get to use the new way of doing things. The less-experienced partner gets a confidence boost for finding a novel solution, and we both get to try something new.
🛠 You’re not great with your tools yet (and that’s awesome).
We all like to feel like we’re good at stuff.
Programmers especially have a tendency to nerd out about being good at using tools. Whether it’s a few handy command-line programs like ripgrep, fd, and shuf, or a deep mastery of Vim vocabulary, every programmer builds up a toolbox of things that make them feel like a god (or at least a demigod).
My weakness lately has been coming up with goofy ways to tunnel around the internet using SSH. I feel like a mole rooting around in a planet-scale lawn. The syntax for setting things up is so painfully obscure that once you finally do figure out how to get something working, it feels incredible. You’re telling me I can run the React Native Bundler on my iMac at work, and this iOS simulator on my laptop at home will just happily connect to it and be none the wiser?!?
When you’re starting out at a new place, or on a new project, you usually won’t have that collection of tools yet. Your brain is going to tell you that’s not great. It’s actually awesome for your team.
Your partner will get to feel like a wizard and be reminded of all the things they’ve already packed into their brain. When you work in a field like software, you’re constantly moving from one thorny problem to the next. That means it’s easy to lose sight of how much great work you’ve already done. Pairing with someone less experienced is a nice reminder for those of us who tend to forget.
It’s also great because it gives you and your partner a chance to teach and learn in a completely known environment. There’s none of the usual extra complexity of actually solving a hard problem. Instead, as the less-experienced partner, you get to practice learning from someone and get clear feedback about how well you’re doing. The more experienced partner gets to practice teaching without also having to solve a hard programming problem at the same time. (It’s tough to do both.) You both get a chance to practice your communication skills and suss out how each of you prefers to give and receive feedback. It’s like the tutorial level of pair programming, and it’s super helpful.
🏚 You’re going to make mistakes (I hope).
Mistakes are what make us, literally and figuratively. You and I are both the result of a whole lot of inaccurate DNA transcription.
Doing the wrong thing is a fundamental part of the learning process. The more you push your field forward in any domain, the more you’re going to have to rely on your internal sense of imagination and correction. Practice using those senses now, while you’re still in the realm of problems that the humans around you know how to solve.
Someday soon, you’ll come across a problem for which there is no StackOverflow answer (😱), and you’ll have to just try something and see if it works. That act of trying is going to be messy. When you guess and check, sometimes you’re going to get it wrong. And that’s great.
When you’re transparent about your mistakes with your more experienced partner, they can help. Sometimes, they’ll help by showing you how you should’ve done the thing. That’s the least helpful option.
Other times, they’ll nudge you towards a better understanding of whatever it is you’re doing by asking you questions. That guides you toward fixing the mistake, but without telling you “do it this way instead.” That’s more helpful.
In either case, making mistakes and being transparent about that helps the entire team to get better at dealing with mistakes in a good way. It reminds everyone that mistakes are going to happen in a low-risk way.
🤩 Pairing with a less experienced dev is a privilege.
A lot of developers, especially lately, in this weird world of remote pairing, worry that they’re a drag on a more experienced partner. That couldn’t be farther from the truth. Pair programming with a less experienced dev is a treat. As a pair, we write better code because we’re looking at the problem from different perspectives. We move our knowledge forward. We teach, learn, and remember how much we’ve already learned. Next time you get to pair with someone more experienced, know that you’re both critical to the job.
The constructive attitude pouring from this article is what makes pair programming a benefit.