Bridging experience gaps while pair programming

Published on May 20, 2019 and filed under Software engineering
by Wouter Sioen and will take

3 minutes

of your time.
In short
We help companies build digital products and bring new juice to teams that seem to jam. We love challenges, they make us shine. We have the brains and the heart to take the most complex projects to the finish line.

Some weeks ago, I was doing a talk about how you can make pair programming effective and enjoyable. Everything went well until I got a question which I couldn’t directly answer. The questioner had some experience with pair programming and asked me how you can avoid getting frustrated when there’s a significant experience gap.

I haven’t had this situation happen for a while, so I reflected on it for a bit. What I learned is that after doing pair programming almost daily for multiple years with a wide range of pairing partners, I’ve adopted a mindset that helps to avoid these frustrations.

There are two aspects during pair programming. On the one hand, you’re writing code to deliver value to your customers. On the other hand, you’re sharing knowledge. The bigger the experience difference, it tends to become more and more like mentoring though.

When you’re in a situation where the knowledge gap is huge, you thus have to take into account that the main focus of your pair programming session will be mentoring. This will help you not get frustrated at the fact that you’re not delivering at a fast pace. It is fine though since this pair programming session will be more of a long term investment, where the slower delivery rate now will turn into more efficiency later.

If there is a pressure to deliver due to an upcoming deadline, it might even be better not to do too much pair programming sessions requiring a high amount of mentoring. This will only lead to a bad experience for both the driver and the navigator because the sharing of knowledge will be the first thing that will get skipped.

There might be cases where there is both a pressure to deliver and an expectation to pair up at the same time. This is an excellent idea when you’re in a scenario where all team members are at similar seniority. If that’s not the case, I would advise you to have a chat with your manager and explain to them why this is a bad idea. You’ll be able to deliver fast but have useless pairing sessions or you’ll be able to share a lot of knowledge but will probably not meet the deadline. There’s still the possibility to find a balance between pairing up on the most riskful tasks and working solo on others to find the best of both worlds while being able to deliver.

Written by

Wouter Sioen

Wouter looks like the nice kid you knew at high school. But boy oh boy, when it comes to problem-solving, this developer is like a pitbull on steroids.

Learn more about Wouter Sioen

Related articles

Pair programming as a newbie and the fear of judgment

Pair programming as a newbie and the fear of judgment

Michał Karnicki

May 24, 2019

The responsible developer profile explained

The responsible developer profile explained

Yannick De Pauw

May 09, 2019

Guiding teams to a better way of working

Guiding teams to a better way of working

Dimitri Van Lunter

March 06, 2019