On pair programming
When I first came to know about XP, I really liked the idea of pair programming.
In software development and, well, in every aspect of life, I like the idea of do things slowly and carefully to get better results, avoid errors and prevent the need to re-do the same work several times. From this perspective, the idea of having two programmers to halve they actual coding time in order to produce better code seems great to me (while people who actually focus short-term productivity doesn’t really buy it).
Some years ago I had some pair programming with a coworker, but we coded little time together in the same machine and I didn’t form an opinion. Recently, I started to work at teams and spent a lot of time making pair programming with a coworker. Now, I really don’t feel comfortable with the idea of pair programming to work in a regular basis, while I strongly believe it has several advantages. Here are my thoughts.
The bad parts
- Programming != writing code
Usually, when you’re programming you’re not writing code. I think that any developer spends more of the 90% of their working time reading code and documentation, or just planning and thinking about the code she is about to write. And two people can’t read easily in the same device. I found myself searching for docs in my mobile a lot while my mate was coding or reading in the monitor. That’s far from performant.
Also, when you’re just thinking on how to code somethings, if you have a person close to you, chances are that she will talk to you and break your focus. This may not happen, but surely will happen more that if you were alone. People tend to talk when they are close, even when there’s not a good reason to do it.
Even when you or your mate are actually coding, there are problems too. I really have a problem with the concentration, for instance. Humans cannot be focused constantly, some minor distractions are inevitable. When you’re coding, if you’re getting distracted, you just stop your work, with no other effect. But, when you’re doing pair programming, when you cease to focus, you’re not reviewing your mate code, and you’re forcing him to wait for you when you return from the clouds and need to read the code he wrote. Also, having to say “sorry, I was thinking about what would happen if I had two middle-aged bearded men as pets, can you explain me what was you doing?” is not the most polite interaction with a coworker.
On top of that, the fact that you have to maintain your focus while viewing how your mate is coding makes things worse. I was a professional online poker player for year’s, which is an activity that requires really heavy focus -since, playing online, you’re participating in several games at the same time-, and I had no problem making my A game for a period of, more or less, an hour. However, while performing tasks that are less intense -like viewing how my mate codes- I find more difficult to stay focused.
The good parts
While I think to just pair-programming 100% of the time is a bad idea, there are certain situations when it’s great, and good reasons to promote it:
- New kid on the block
When you’re new in an organization, to be introduced into the codebase while pair-programming is really better than not. Period.
If you have a good senior developer in your team, the most profitable thing you can do with her time is to mentor junior developers. And mentoring usually involves pair programming.
- General knowledge
A lot of important things that you may do while coding doesn’t show up in the code itself. The proper use or your IDE or editor, tricks involving multiple cursor or file searches, the proper use of debuggers or the chrome dev tools… those kind of things are really valuable and you can’t learn them just by peer reviewing code, you must see someone working with them.
- Avoid essential developers
As a manager, you don’t want all your project to depend upon the availability of a single worker. Developers can leave your organization suddenly, get injured -we lost a devops for a month in our project due to a shoulder dislocation recently- and, well, they can eventually die. The best way to make the knowledge flow among your team and organization is to promote pair programming.
As a developer, I find pair programming to be uncomfortable when it last more than a small amount of time. Also, I think it is not efficient if the main goal is just to write quality code, and that peer review could achieve that goal better.
However, there are things in programming not directly related to produce quality code that does have a huge impact in the performance of a team or organization. As a team manager, I would enforce the developers on my team to have sessions of pair programming regularly, so no one is essential to the team and every developer in the team can learn from the others.