How Three Months of Pair-Programming Has Impacted My Developer Career
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.
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.
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.
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.
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! 😊
Interested in reading more such articles from Annie 🦄⚡?
Support the author by donating an amount of your choice.
Yes! This is awesome to see!
I've long been a big advocate for pair programming. Sadly, as careers go on, software engineers become less and less interested in pairing, for some reason. I've seen a senior engineer storm out of the room when it was suggested that they pair program on a ticket: "I don't need to pair! I'm not a child!" (true story).
A couple things I'd like to add to your post—if I may—would be that effective pairing starts with good expectations and setup.
1. — It helps if you can have a machine setup that you're both familiar with (you're probably going to have to disable a lot of the short-cuts, sadly), and you 100% need two keyboards (however that situation looks)... I used to bring my external keyboard to work with me so I could hand my laptop to a pair, and use my own external keyboard at the same time.
2. — You'll also want to ensure that you keep taking breaks, as it can be intensive. IMO also, it's okay if some things are not paired on. When you get good at pairing it's easy to know when something is a pairing thing and when it's not. However, a mantra I had in an old team was: "default to pairing". i.e a task should be shown that pairing isn't necessary, not the other way around.
3. — If you've never tried "Ping Pong Pair Programming" I highly suggest you do. Or another exercise that's great is just setting a 10 / 15-minute timer and swapping whoever is driving the session (this is a lot more useful than it might sound). And as a rule of thumb, I bias towards the least experienced developer having fingers on the keyboard.
Anyway, these are just some general thoughts or ideas I wanted to throw into the mix. I don't see a lot of posts about pairing nowadays, and apart from teams I've introduced pairing to, I've not actually seen it ever in the wild throughout my career.
Thanks for the write up ✌️
Wow Lou, really appreciate you sharing and adding some very valuable thoughts to this conversation!
I've tried ping-pong pairing in bootcamp, but not with my CTO. Reason being is that when we work on some of his stuff, I haven't the foggiest where to start- the gap in knowledge is too wide at this point. Definitely hope to try other types of pairing in the future though, as I skill-up!
(Also, we could be better at taking breaks... 😅)
Thanks again, Lou! 🙏
Awesome post, I feel like I would absolutely THRIVE if given an opportunity like this. I'm hoping I get one in the future once I get out of boot camp.
This probably changed my perspective on pair-programming for the better. Definitely going to try it out more now!
Thanks Annie 🦄⚡!
Annie 🦄⚡ this is spot on. Great work.
Pair programming can be so disorienting, but eventually you get accustomed to it. I think it's also a better product when more minds attack a problem or equation. Keep up the great work!