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.
Top comments (10)
Great post! Have you ever ran into a situation in pair programming where one person wanted to follow TDD and the other didn't?
It hasn't happened to me so far. The thing is that I work in consulting, and our clients assume we're going to work using TDD and Pair Programming, as learning them is one of the main goals why they hire us :) Apart from this, IMO TDD and Pair Programming are a killer combination, and somebody reluctant to do TDD would be easily convinced of its benefits after a couple of weeks.
Interesting. I can see that if you were hired as a consultant to teach TDD, then everyone is open to learning it and changing their workflows. What type of development are you typically doing? My latest pair programming experience was on a single page JS application. I've changed my workflow over the past ~1.5 years to follow outside-in testing. Not too long ago I was in a pair programming situation for a couple days, and I found that my partner was not very experienced in testing, but had been doing frontend development for awhile and was pretty set in their ways. Needless to say, pair programming didn't work out and we went back to developing on our own so that we could follow our own development styles. I found it extremely challenging trying to convince them of TDD, when testing was already new to them and testing isn't as common in the frontend world as in the backend world.
In the last couple of years I've worked mainly in the backend world. Interesting story, changing the way somebody has been doing things for years is not easy. How long did you tried pair programming before going back to soloing?
Probably a few days a week for ~2 months. We were working on the same project and tasks were broken out in such a way that there was lots of overlap, so we were sort of forced to work together and pair. A big challenge I found was sometimes my partner would come in earlier and start cranking on tasks and not follow TDD. Lots of changes would be made targeting many tasks instead of focussing on one, resulting in lots of broken tests. Then I would get to work and we'd have to backtrack and fix the broken tests and write news tests after the fact. After the 2 months, I suggested changing the team structure so that we could work on different things at the same time, allowing each of us to use our own workflows.
Thanks for the article. I never gave a serious thought to pair programming, but now your article almost convinced me to give it a try. I think both having their own computers would be helpful. The reviewer should access the developer's computer through RDC. That way, he can work on both computers as needed.
Very interesting article, I had a totally different idea about pair programming(bad one) I will apply this for my next Sprint, I will post the output at the end of it!
Thanks, it will be great to hear your experience! I would try it for at least 6 weeks before coming to any conclusion anyway, it takes some time to get used to it :)
A small tip regarding the weirdness of googling: the navigator should have an easy to access to a laptop to be able to investigate/research at the same time.
Thanks for the great write up!
We sometimes have a laptop at hand, and it can be useful, but dangerous too. It's easy that the person with the laptop gets distracted...What it's essential for me is having two keyboards and two mice for Pair Programming to work well.