My Experience with Pair Programming

Four years ago or so, I was working in Madrid (Spain), and I did an interview for a company that was using Extreme Programming as a methodology. At that time, I had no idea about what that was, so they explained it quickly: "Every morning, we have a stand-up meeting, where we speak about what we did the day before. Then, we review that whiteboard full of post-its, which represent tasks, and each pair, because here we do Pair Programming, chooses a task and works on it".

That sounded extremely different to everything I knew (I was still doing waterfall...), and, to be honest, I was a bit reluctant, mainly because I didn't see myself working full-time with somebody else and sharing the same computer. "I won't be able to listen to music!", I thought. This, along with the fact that the technologies they used didn't catch my attention, and that I was quite comfortable in the company I was working for, made me reject the offer they made.

It's 2016. I've been living in London since 2014, and when I made the difficult decision of moving to a different country it was crystal clear to me that I would try to make the most of the experience. So, since day one, I began to attend meetups, workshops, etc, as in London you can find plenty of these events. In many of these workshops we did Pair Programming in case studies with the objective of familiarizing ourselves with technologies, practices, etc. Last year I attended the Global Day of Code Retreat, which was amazing, and where you basically spend the whole day pairing with different people.

I started to think that Pair Programming wasn't that bad. I enjoyed it a lot, I realized I learnt a lot too, and, given my increasing interest in TDD, and technologies like Spring Framework, Cloud platforms and many others, I found a company where I was going to be able to use all this and much more.

After one year of pairing, I think I'm now in a position to give my opinion about full-time Pair Programming. Yes, we work from 9 to 6 sharing a computer with another person, but we don't share keyboard and mouse, since each member of the pair has his/her own one. The usual approach to pairing is that one person takes the role of driver, being responsible of coding, while the other person should avoid touching the devices and just review and talk about what the pair is doing. To avoid tedium both roles are interchanged frequently.

The pros

There are lots of pros, and they defeat the cons completely, in my opinion:

• Since two people are working on the same problem, and every single aspect of the implementation is discussed, the pair doesn't make the same number of "stupid" mistakes that we make when we work alone. This kind of mistakes makes us waste a lot of time, and I guess all of you know what I'm talking about
• You learn tons: this happens because your pair will always know something that you don't know, starting with simple things like command line tools, and more generics aspects like patterns or features of the language we're using. This point reaches its maximum potential when you're working in a language you don't know well, but the other member of the pair masters. I can't think of a better way to learn a new programming language that pairing. Believe me, the experience is awesome!
• You teach tons: same as the other person will know things you don't know, the inverse is true, and you'll find yourself explaining to your pair how to do certain things. Apart from how satisfactory teaching is, you'll see that teaching is a good way to review your knowledge, and discover holes in it
• The knowledge is shared: pair rotation is frequent if you stick to Extreme Programming practices, so the "single point of failure" problem is effectively removed completely, and nobody will start shaking if one member of the teams is not working one day. Indeed, through pair rotation it's quite hard that a single developer is absolutely essential in the team. This can break the traditional way of thinking in many companies, because it challenges the corporate ladder model slightly. You know, you own a niche so that promotion is easier. If you think this way, stop to think if you're looking for a personal benefit or a team benefit in your office when you go to work. A team benefit will always be much better for your company, which is paying you good money to receive the maximum value in return
• It's fun: people are social beings, we like to talk to people, discuss things, make jokes. Pair Programming encourages this all the time, so the idea of the isolated programmer hearing music during the most part of the day disappears completely. Personally, I think this is very beneficial for our mental health in the long run too :)
• It helps to get more cohesive teams. In the book Peopleware we can read about the concept of "jelled teams", teams that achieve cruise velocity and are unstoppable. Reaching this ideal is not something we can do in one day, and I can't think of a better way of achieving this than Pair Programming
• The code generated has less mistakes: when we do Pair Programming we're doing code reviews all the time, so the percentage of bugs decreases considerably

It's quite likely that I'm missing something, but I think that after reading all these points you should have a good idea about all the benefits of pairing

The cons

As everything in life, there are some cons, even though I believe most of them can be mitigated:

• It's exhausting: my first weeks doing Pair Programming I left the office exhausted, and not because I'm a weak person, everybody in my company mentioned that it was very common. Spending the whole day speaking to another person and completely focused on your work (because distractions are less common than when you work alone) makes your mind be drained at the end of the day. However, we usually adapt quickly to new environments, and in three or four weeks you get used to it. In addition, breaks are highly recommended, and we have started to adopt the Pomodoro technique, which has proven to be very useful to keep us focused and less tired
• Keyboard and mouse collisions: in occasions, the person that in theory shouldn't touch the keyboard and mouse, can't avoid doing it to comment something that it's complicated without using the devices. Most of the times we take control unconsciously and it can be a bit annoying for the other member of the pair, but this situation it's hard to avoid. When it happens, the best thing we can do is taking it with humor if you're interrupted, and if you want to interrupt, try to alert politely (can I take over for a while?)
• Searching something / Googling is a bit awkward: when we're stuck and we go to Google to look for a solution, I have noticed that every person reads the contents randomly, so we're actually following two different lines of thought. From a point of view, this can be beneficial, because maybe we find a solution faster, but many times I think I would do it more comfortable if I did it alone. When this happens, it's perfectly valid to propose the alternative of investigating in parallel using two different computers
• Personality clashes: each person has a different character, and so many hours working together can lead to some tension if there are disagreements. I have experienced this situation working with client developers more than with colleagues of my company, as our recruitment process is very focused on finding the right people for our way of working. Patience is super important when you pair, and you should never be rude with the other
• Disconnection: if you feel that you're disconnecting from the task you're doing, or this is happening to the other one, the best thing you can do is proposing a break. We have ping pong tables in our offices to facilitate having proper breaks, as we disconnect completely from the task we're doing to play ping pong for a while

Conclusion

I don't know if this article will convince anybody to do Pair Programming, but at least I expect it's clear now why it is such a recommended practice. If you want to learn more, have a look at Kent Beck's Extreme Programming Explained.