These days, I’m always eager the first time I have a chance to pair program with someone for the first time. Whether they’re more or less experienced than I am, I know that we’ll most likely learn a ton from each other. Maybe they’ll make me explain something I thought I understood, but in fact had incomplete knowledge of; or maybe they’ll take something that used to intimidate me and make it easily relatable. It’s always a learning opportunity for both parties in some way.
A few years into my programming career, it was often an anxiety-inducing experience for me to even think about working with a more senior developer so closely. To see them see me work. Would they think I’m useless? Would they notice that I don’t understand some basic computer science principle they might deem necessary to do my job? Or would they find my tools inadequate compared to theirs?
These fears were all rooted in my convinction that my pairs would discover that I had no idea what I was doing. Which to be fair, was true and still is, in many respects.
Thankfully, as many programmers find out as their career unfolds, the dreaded unmasking moment doesn’t really ever happen. That is, unless you’re unfortunate enough to encounter a toxic programmer who feels powerful when they put down other people or who somehow decides to self- righteously gatekeep against the uncivilized hordes of junior programmers.
If you ever encounter someone like that — or if you already did — please know that the problems is theirs, not yours. I hope you can find a way to isolate yourself from such toxic people or find diplomatic ways to ask them to quit acting like assholes. Sure, you may be able to learn some techniques from them, but you also risk adopting horrible habits that will negatively impact your own career and the well-being of your team. Additionally, these toxic people survive by turning other people into toxic people. That way, they don’t seem that bad. They are bad.
What should happen after a few uncomfortable pairing sessions is that you find some comfort in pair programming and you start to realize that everybody has some knowledge or perspective that can benefit the other pair. But also that everyone becomes a bit better at pretending they have their shit together as time goes by. Whether it’s because it bolsters someone to feel like their expertise and opinions are valued by their peers and pairs, or because they start to notice their own growth through engaged collaboration and discussion.
Although it might be anecdotal evidence, I didn’t get fired right after my first pairing session with a much more senior developer. After a while, I started finding solace in the fact that if I had been so shockingly bad my pair might have taken the time to put me out my misery. Or at least take me aside to tell me what I needed to improve.
I know that proponents of pair programming can often seem a little too eager. It’s also hard not to feel intimated by people who seem so comfortable with their own skills that they’re willing to have them scrutinized up close. It feels as if they actually want to be micro-managed by a fellow programmer.
But this is not what healthy pairing looks like — even beyond programming. There are many styles and flavors of pairing. Some, like mobbing even sound dangerously close to the dreaded Design by Committee. My simplest token for a successful pairing session is engagement. It’s harder to get this right in remote pair programming scenarios — which is what I do the most — because you often can’t see your pair. You may start to get the creeping sensation that one of the pairs is going too fast and that their pair checked out either because they don’t feel comfortable enough to ask a question, or because the rhythm doesn’t work for them, or worse, because they feel that they have nothing to contribute — which is not true.
Even a very senior programmer has something to gain from collaborating with a complete beginner. For example, while they have many more experiences to draw from, experts also make many assumptions based on past experience or reject ideas because of past battle scars which may not longer be relevant. Beginners don’t have past that much experience to build biases from and they naturally have fewer horring stories scaring them away from trying something new or different.
In the case of software, an experienced programmer could be trying to shoehorn a solution that has worked before instead of trying something that may be more appropriate to the specific problem at hand. Or they could assume that a complex solution will be more sustainable without bothering to make the case for its upfront cost to their less experienced collaborator. Even if it worked before, you still have to convince your pair that it’s good idea. Having to prove the worthiness of a solution that may appear not to require proof is precisely why pairing with diverse people is incredibly valuable.
By diverse I mean actually diverse: ethnically, linguistically, philosophically, sexually, physically, gender-wise and age-wise. Biases and assumptions are everywhere and they are preventing us from seeing alternative paths and solutions that can be simpler, more elegant, and more sustainable just because we’re dogmatically holding on to the solutions and perspectives we’re comfortable with. More importantly this is how the best teams are built.
Some of my best pairing experiences ever came from working with people who had different gender, ethnicity, and knowledge than me. They might have known more about computer science, but I had a bit more practical experience with building software; we weren’t offended or bothered by the same things; we didn’t even feel challenged by the same kinds of problems which meant we could take turns supporting each other depending on what kind of task lay ahead.
All of this is to say that the fear of pair programming is valid. You’re not weird and sheepish for having it. If you’ve managed to prevail over that feer, great! Help others do the same. But don’t forget how hard it was to imagine before you succeeded over the hurdle. If you’re still looking at pairing like a huge monolith looming over you, also know that there are plenty of people who successfully work without it. My opinion is that they’re missing out, but that doesn’t mean I don’t like to work alone from time to time so I can dive deeply into a problem on my own. Even if the growing rabbit ears often remind me that I’m missing my pairs.