It's been about three months since I began consistently pair-programming. Although it didn't start off smoothly, I can definitely say it's been a valuable addition to my somewhat new developer journey.

Here's how it started, the progress, and what I've learnt along the way.

For context, I work at a start-up where I was hired as employee number one. This means, at time of writing, I'm currently 25% of our entire company, and 50% of the "Engineering Department". The pair-programming I do is with my CTO.

How It Started

I'd always been vaguely interested in pairing, but it wasn't something I had much experience of. My first developer job was at a small fast-paced agency. Everyone worked on their individual client projects, so it wasn't really a part of the company culture. I'd previously pair (and group)-programmed during bootcamp, and like most other students, being a new thing, we all found it a little awkward.

My interest was piqued by this (oh so timely!) tweet from James Tucker, a week before I started my new job:

During my on-boarding, I mentioned this to my CTO and he was open to giving it a go. We decided to incorporate it into our workflow and agreed that we'd slack each other whenever we wanted to pair.

However, this did not go to plan.

Neither of us were in the habit of pairing and honestly, I had so much imposter syndrome around being hired for the position (moving from a largely HTML/CSS role to a full-blown React/Redux environment), that I was hesitant to ask because I didn't want to reveal how "terrible" I was.

Two weeks went by with little pairing. The first week was fine; I was ramping up, getting comfortable, and working on small UI enhancements and bugs.

Then I started work on my first fully-fledged feature. This involved A LOT of things I was unfamiliar with; mainly dealing with multiple libraries, timezones, and JavaScript/React in general. In my week three one-on-one, I broke down and mentioned my struggles with the massive codebase, and the panic that had been gradually building up.

My CTO was very supportive and understanding. First, he assured me that they hadn't expected me to be React ninja from the get-go, and that an important and very valid part of my job was just to learn. They were aware of my abilities before hiring me. He then immediately came up with a game-plan, and we formally scheduled two weekly pairing sessions henceforth.

The relief I felt about how it was handled was palpable.

How It's Going

As the weeks went by, we've gotten more comfortable pair-programming with each other. For a while, our two scheduled weekly pairing sessions turned into four, as we started to ad-hoc slack each other to work together beyond our scheduled times.

Sometimes the sessions are short; I'll just need an extra pair of eyes on a bug, and sometimes they're a couple of hours or longer.

We'll pair on fixing bugs, breaking down and implementing feature work, and occasionally have mini-learning sessions. For example, we're slowly transitioning our codebase to TypeScript & my CTO talked through what he'd done so far, his learnings, and next steps.

I usually ask a million questions, take notes, and often like to repeat things back to confirm and check my understanding.

The Positives

Familiarising myself with the codebase has been a much faster process through pairing, and it's great to get immediate answers to any questions I have. I also figured out that I have an easier time understanding concepts when I hear them, as opposed to just reading. In debugging code together, I've also picked up on computer science concepts that weren't taught at bootcamp (such as race condition).

But an unexpected benefit has been that I've been able to observe and assimilate many of my CTO's habitualised ways of working. This includes small tricks with VSCode that I didn't know about, such as shortcuts and how to more efficiently navigate my way around the user interface.

Seeing first hand how my CTO, with his years of experience, approaches a problem has been immensely valuable. For the first time, I've really started to appreciate the importance of reading documentation. If there was something we didn't know, his response is always, "Let's have a look at the documentation…" 😅

I would also say that working together more closely (although we've never met in real life) has fostered teamwork and goodwill between us, both of which are important in building a positive company culture.

The Negatives

It requires a certain amount of vulnerability to pair with someone much better than you. I constantly feel "stupid" for not knowing or forgetting things. It's hard to admit how much you don't know yet, especially when you're trying hard, and want to show your best side in front of your employer.

Luckily, I don't get treated as such, however, it's an internal battle I face each time.

For the most part, it's also currently a one-way stream because our levels are so different. By this, I mean, I feel like I usually benefit more from the sessions. However, I once helped solve a CSS issue and made it even better than it was… that felt awesome! And my CTO has mentioned that pairing has forced him to examine how he's explaining his thought process, and so it's been beneficial for him too.

In Closing

Would I suggest adding paring into your workflow? Absolutely, if you get a chance!

It might take a bit of time to get used to but I'm much more comfortable with it now and have since paired with other devs to help them out. It feels great to pass on knowledge/tips you've learnt and solve problems together. Plus you get to practice speaking the language of your craft.

You can use any screen and voice sharing application to pair, and VSCode itself has some pairing extensions you can install, such as Live Share.

But if you happen to use a Mac, I can highly recommend Tuple for pairing. Ben Orenstein and his small team have done an amazing job with it, and are responsive to any feedback. They've also put together an excellent Pair Programming Guide to help you get started with it.

---

So hey, thanks for making it all the way down here! Hopefully, you've found this article useful and it's given you a better idea of what pair-programming involves. If you're into the social thing, I share tips and observations on my dev journey on Twitter. Comments or questions? Drop 'em down below! 😊