How Pair Programming Unlocked My Growth as a Software Engineer

I didn’t set out to become a big advocate for pair programming, I just happened to land on a team where it was the default way of working. At first, I didn’t think much of it. But looking back, it was the single biggest factor in my growth as a software engineer. In this post, I’ll share my journey, how pair programming shaped my skills and confidence, and why I believe it’s one of the most underrated ways to accelerate your development.

My First Experience With Computers

Let me take you back to when I was gifted my first PC as a child. I was obsessed. I used it for everything, from playing games, nudging friends on MSN messenger to doing my homework the night before it was due. But it wasn’t until I studied for a GNVQ in ICT that I was first introduced to “programming”. At least, at the time I thought it was programming, but really, we were just building basic websites with CSS, very basic JavaScript and HTML (who remembers the <marquee> tag??). For me, having had access to computers for a few years, I found it very easy and loved being able to build websites, so much so that I built one for my Scout group at the time.

Starting My Career and Struggling Alone

Fast forward a few years. I’d finished school and university, graduating with a degree in Mathematics and Computing. I landed my first job at IDG (now Foundry), a publishing company that produces magazines such as PCWorld, MacWorld, CIO and more. My team, of around six engineers were responsible for maintaining the large number of websites IDG produced. Most of the other engineers had worked there a long time and were very experienced.

Now, looking back and being honest with myself, I didn’t exactly thrive while there. I’d never heard of pair programming and we always worked solo, headphones on, in silos. It took me a long time to learn even the basics of the language we were using (Coldfusion). Sure the choice of a closed source, paid for programming language didn’t help, meaning there was little guidance online. All I had was a book handed to me on my first day. Just a few months in, I already felt demotivated and uninspired, which led me to start exploring other job options.

A New Beginning at Sky

After a year at IDG, I managed to gain a place on the Software Engineering Academy graduate scheme at Sky. This started with a month long intensive training programme, followed by a short six-month project with the other graduates. This introduced concepts such as version control, TDD and pair programming to me. After that I joined a real team on a real project. We were tasked with breaking apart the third-party developed monolithic backend that powered Sky Go into smaller Java services. The team I joined was newly formed, and as Sky were only really just getting going with in house software engineering, the rest of the team were hired as contractors. All of them were highly experienced senior engineers.

Going All-In on Pair Programming

It was decided early on that pair programming would be the default way of working. Eight hours a day, five days a week, with daily rotations. Each day, I’d pair with an engineer who’d been on that workstream the previous day. The next day, they would rotate to something new, and another engineer would join me. Of course there were times where we were an odd number of engineers due to holidays or sickness, and in those cases we would work solo, but most of the time, we were pairing.

No one had laptops. We just had shared workstations that were all set up the same way. Two monitors, two keyboards and two mice. So either of the engineers could take control at any time.

The Results: Rapid Growth and Promotion

At that point, I’d only had a brief introduction to pairing during onboarding, so I didn’t yet understand its full power. But wow, did I learn quickly and grow substantially from that point onwards. In the space of months I’d gone from a junior engineer who barely knew Java, to confidently contributing to the project in various ways from design, testing and coding. I had so much one-on-one time with senior engineers it was impossible not to learn from them. Not only did I learn Java, I learnt various techniques, what they do when they’re stuck or learning something new and pick up their tips and hacks that they’d accrued over their many years of software engineering.

18 months later, I’d been promoted. Another 18 months after that, I was promoted again, to Senior Software Engineer leading a completely new team on a new project. Without pair programming, I doubt that would have happened.

I was lucky to have been surrounded by such talented, friendly and experienced engineers. I know not everyone is as lucky. But it’s never one way. It’s never just the junior engineer learning from the senior. As a senior+ engineer I’m learning new things all of the time from engineers of all levels.

Looking back at my time at IDG, had we pair programmed like we did at Sky, I have no doubt I’d have thrived and grown a lot more.

A Note of Thanks

I don’t know if any of my old colleagues will read this, but if you do, and you know who you are! Thank you for being so open and friendly. I learnt so much from you all and I hope to be able to pass that on to others in the future.

What’s Next in This Series?

This is the first in a series of blog posts about pair programming. In upcoming posts, I’ll explore what pair programming is, why pairing should be your default way of working, and share practical examples to help you get the most out of it.