In favour of paired programming

As CTO, paired programming was first presented to me by a developer as a method of working several years ago.

We had at the time only 2 programmers on this developer's team - and my immediate thought was that instead of 2 people coding we would only have 1 person coding - so surely, the output would halve!

It's always good to challenge basic assumptions so I gave it the green light for a trial.

As it turns out, I'm very happy that I did. I now see paired programming as a specialist tool in our workflow, one that we deploy most days.

However, it must be seen as that - a specialist tool. It shouldn't be brought out all the time, as when used incorrectly it can have an adverse impact on output, wellbeing and code.

How to paired program

There are many styles of paired programming - most of them use a passenger/driver car analogy - and it's important to define at the beginning of any session which style you are going to use.

But before you decide, you should really bring up VSCode's Live Share with a friend and give it a whirl. It's what happened if Notepad++ and Google Wave got together 10 years ago and had a beautiful baby that has since made a lot of great life decisions. Any number of collaborators can code on the same codebase in real-time, live-follow each other's code and alert team members to other relevant areas of a codebase. You can share environments, terminals and even more.
Supplement VSCode with your Zoom software of choice, so you can chat freely and screenshare non-code related stuff as you go.

Anyway, back to the car analogy. Nobody likes a back-seat driver, so if you define beforehand who is going to be navigating and who is going to be pulling the levers, you are going to get to your destination with a lot less arguments.

At the beginning of any session, decide

• Who is going to be writing the code?
• Who is going to be talking through what is going to be written?
• Who is going to ask questions about what needs to be written?

Rules are made to be broken, but the most important thing is to stay communicative and respectful of your decision throughout your paired programming session.

Where paired programming shines

For brand new team members, consider a long paired programming session as part of their onboarding. With their first few tasks, work through it with them. It's one of the fastest ways for somebody to get acquainted with a codebase, and also for them get to know their new colleague(s).

For junior team members, it's a great way to learn how to create code and problem-solve when following a more senior member.

And for more senior members, it's a great opportunity to teach and mentor.

For everybody, it's the fastest way to explain code, to share knowledge how a piece of functionality works or to explain their design decisions.

In my personal experience, I've found paired programming a fantastic way to debug large-scale problems. If there's something that just can't wait, 2 heads are better than one. You can together talk through the code, question assumptions, and hopefully spot problems a lot sooner.

And finally, paired programming is form of socialising on-the-job. It strengthens team connections, passes the time faster, can be very fun, and you share the dopamine rush of achievements, big and small. All these things are fantastic for productivity improvements long after the collaboration session has ended.

Collaborative Documentation Sessions

LiveShare is also a fantastic way to write documentation for existing functionality. Start with the question, "what don't I know about the codebase?", pick a piece of functionality and create a new document.

Together, start to throw down scrappy notes and questions you may have. As you talk and discuss through each point, team members holding knowledge can grow the notes and questions into full sentences, lists, and even diagrams.

If nobody knows, or you're ever unsure - you can together start poking through the codebase, and discuss your findings along the way.

Within a very short timeframe, you'll have a fleshed-out document about something you previously knew very little about.

Where to avoid paired programming

Paired programming should be seen as a way for a varied team to work effectively together, especially to compliment each other's abilities.

It's not an excuse to be lazy - quite the opposite - it's an excuse to gain or share knowledge, or reach conclusions faster.

If when paired programming, one person is becoming bored or disengaged, or does not give or gain out of a situation - it's a good time to question why you're there.

You should consider paired programming often, but that doesn't mean you must paired program often. Look for those opportunities - to teach, to question code, to debug faster or to share knowledge faster - and reach out to a team member to collaborate. Don't do it to be lazy, or you'll end up with less code than if it had been worked on it alone.

Sessions can be started quickly - and they can be ended quickly, too!

And never use it as a replacement for Code Review. Your code should always be reviewed by somebody who has not had any part in its writing.

Final Thoughts

The best programmers are good team members; eager to learn and eager to teach. They are focused on quality code, and shared knowledge - not lines written, or measurable output. Paired programming is one of the most important tools you can have in your arsenal of empowering your team to be the best they can be.