My second attempt at Pair Programming

There are tons of resources about Pair Programming out there, but I believe this quote from Wikipedia summarises its essence:

Pair programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.

My first attempt at Pair Programming was a long time ago; it was probably around 2008 while the concept was still novel in Argentina. To be honest, it wasn’t such a good experience back then and I became skeptical about it. But last week, I had the chance to try it again. Actually, it wasn’t a choice but more of a requirement from a consultancy joining our team who always work in pairs. As I always try to keep an open mind, I got rid of my prejudgments and gave my all to make it work.

Firstly, I have to thank the team that worked with me, as they dedicated a lot of energy to the task and created a good environment.

I had to learn a couple of things and some of them really made me change my mind about my Pair Programming concerns, realising that most of them were because of not doing it properly. So, let me organise this by starting with my concerns and how I learned to overcome them.

My concerns

The risk of biased pairs:

One of my main concerns was that when somebody works with another person for a long time, it naturally creates bias, which leads those two individuals working as one. After that moment, you won’t get any of the benefits of Pair Programming.

When I first met the team, it was me and 3 engineers from this consultancy and they asked if I wanted to pair with one of them, and that, the next day or week, I could pair with somebody else and keep rotating frequently. Wow! Rotating pairs definitely help with avoiding bias, plus they also help to share knowledge and break the silos. My first concern disappeared quickly with a novel yet easy solution (it was novel for me, at least)

It doesn’t look like a good use of resources putting 2 people to do the same job:

To better understand this concern, you have to go back to 2008, which was when I had my first Pair Programming experience. Back then, we worked at a workstation with only one small and low resolution 14" screen that we had to share and physically swap places if we wanted to change who the driver was. It was definitely an uncomfortable way of working.

This time, I was asked to have a second mouse, keyboard, and a mirrored screen connected to my computer. And I definitely felt shocked by the idea: how were we supposed to work like this? But after an hour, it all made sense: each of us could look at one screen and eventually, they could take control of the computer without having to switch places. A side effect of this setup with mirrored screens was that I could focus more on my task and had fewer distractions due to fewer interruptions.

If you think about it, having 2 people reduces the error rate without the need for a code review, so eventually, you’re making better use of your time. Do you know how much time you spend on code reviews? Isn’t it worse if you don’t have the context of the task? But since I like code reviews, let me dive into my next concern.

Not doing code reviews:

I’m a firm believer that code reviews are really useful to gather feedback from external teams, but if your changeset is big, the reviewer won’t have context; likewise, if it’s too small. There’s a delicate balance that’s generally hard to achieve.

So, if you’re avoiding biased pairs by rotating, and the team has a shared mindset, then your pair might be better reviewing your code than any external reviewer who’s hurried to go back to their work. The reason is simple: they’re involved, have a broader understanding of what you’re ultimately trying to achieve, and also has a common understanding of your team’s standards.

Key benefits of Pair Programming

Increased quality:

As you keep rotating and you work with other people with high standards, you get motivated to follow best practices, you learn and you improve. You’ll find yourself taking fewer shortcuts (i.e. you won’t be so easygoing about not writing a test case due to having to deliver something fast).

Better working environment:

It’s amazing how you feel closer to your teammates when working in pairs, it feels like you’re sharing something together, and besides, you have more opportunities to talk about your life. If you’re stuck, you can take a break together, have a coffee, talk about anything and then come back to work. That creates a more enjoyable workplace.

Fewer distractions:

As mentioned above, if you’re working alone, it’s easier to check your social networks, check one funny message or just read some news or something. When you have somebody working with you, you have to be respectful with that person and focus on your part, and this goes both ways. It doesn’t work if you’re the observer and instead of observing you’re playing with your phone. If done right, you’ll get things done faster than before just by using your time more efficiently.

You learn to be more productive:

By watching how others code, you can learn from their shortcuts, refactoring tools, some new pattern you didn’t know about, or even new technologies.

If you’re a junior software engineer, you get to learn from more senior people, and if you’re senior you get to learn from juniors. Indeed, they usually know better than any senior about the latest trends in technology.

Some things are better in pairs:

Like Test-Driven Development (TDD), which is easier when one writes the tests, the other fixes them, and then you switch roles (aka. ping-pong programming). When doing TDD by yourself, sometimes the code is not well prepared to be tested and you end giving up or taking shortcuts. Your pair will help with your thinking process, providing a different point of view and pushing you forward to maintain best practices.

What are the challenges?

• The team has to have shared knowledge and understanding of the goal they’re working on, otherwise, rotating pairs becomes difficult and time-consuming due to context switching. This is usually solved by doing a kick-off meeting to lay the groundwork and agree on the solution, plus holding regular daily meetings to have everyone aligned and updated.
• Tasks have to be split into small chunks of similar size, allowing each pair to finish them at the same pace. If a team spends 4 days working on a task, while the other spends 6, rotations become harder and ownership unclear because the pair won’t own the task until it’s done. To tackle this, you’d have to have a meeting to groom your tasks and split them if they’re too big. If the tasks are small enough to be finished in 1 or 2 days, then it doesn’t matter if a pair picks 2 tasks of 1 day or 1 task of 2 days.
• How to deal with specialised engineers: it’s common to have people more focused on front-end development and others on the backend. But having to do both will always help you be better. You have to be open (sometimes, this is quite a big challenge for some people/teams), and if possible, pair with people from different areas of expertise.
• You need at least 4 engineers: with 2 you can’t rotate pairs, with 3 one doesn’t have a pair or you have a mob of 3 engineers working on the same task. I believe 4 is the minimum but as nowadays teams are 6 to 8 engineers on average, this shouldn’t be a big issue.
• How to deal with employee’s time off: eventually you’ll have pairs without somebody to pair with. There might be several workarounds to fix this issue and eventually, it shouldn’t happen that often, so my take is not to worry too much about it. However, it’s something to consider if your team is remote or work from home a lot, etc.

Conclusion

I realised that without rotations, you shouldn’t be doing pair programming. I’m not saying that it doesn’t make sense but you’ll get the most out of it by having at least 4 engineers. Today, it’s not uncommon to have a team of 4 to 8 engineers working on the same backlog, so this shouldn’t be a big problem.

Secondly, you’ll need a good setup of hardware resources: notebook, screens, mice, and keyboards, to make good use of your engineers. And I forgot to mention, you’ll need space; you can’t sit two people at a one-person desk.

If you have all of that, I do believe that Pair Programming can help to revamp your team’s culture, improve your code quality, and spreade some good vibes in your work environment.