At the top of /r/programming is an opinion piece titled Pair Programming - My Personal Nightmare. It’s an interesting read, touching on introversion, creativity, and pair programming. As an introverted agilist who pairs daily, I felt the need to respond.
This comes from the vantage point of someone who finds pairing particularly beneficial when it comes to the work I’ve done the most of — enterprise Java web applications.
Basically, we believe that two heads are always better than one.
This largely depends on what we’re trying to accomplish. Maintainability (and thus, readability) is often the goal of the software I’ve written for enterprises. Inevitably, what is beautifully concise and readable to one developer is an indecipherable mess to another. Bringing in another head, so long as they’re comfortable sharing their opinion, ensures that we’re consistently producing something that at least two people on the team can read and maintain.
Just in the world of programming, some great works of innovation and craftsmanship have sprung not from a team or a pair, but from the efforts of one person.
I certainly innovate better on my own than in a team.
For the vast majority of programming I and most other developers will ever do, creative or clever solutions are not in order. While at a Spring-Hibernate client, I wouldn’t be doing them any favors by deciding to skip the servlet-based architecture to use Webbit with MyBatis, though I could produce a more innovative solution this way.
Simply: some people enjoy this style of work, and so they prescribe it, vociferously, for everyone.
Often I go home exhausted, but knowing the solutions we’ve come up with will likely be understood by the majority of the team. In turn, this reduces the pressure that comes with soloing on a project. While the act itself isn’t always enjoyable, the outcome has produced better results for me than alternatives.
But when they take the next leap and advocate (or mandate) the practice for me, because they “know” I’ll benefit from it (and have “data” to prove it!), slow down.
Consider a broader perspective on the technique. Pairing may not always be beneficial to the individuals on a team, but still a worthwhile pursuit. It aids in creating readable and maintainable solutions, even if it may make the day a little more difficult for folks like the author and myself.