Pair programming is one of the more interesting trends in the profession of software creation. It’s particularly interesting to me because it is the primary issue on which I differ from the thought leaders. In this essay, I examine some of my worries about the general applicability of this practice.

Programming is still a fairly young profession (in comparison to medicine, physical engineering, scientific study, or the creative arts). As a result, we are not only still in the process of determining best practices, but also the nature of our profession, the students it attracts, and our culture. Are we more similar to artists or to engineers? Are we, like medicine, an intersection of science and practical experience?

Some people consider the creation of software to be “software engineering,” which has a very impressive sound to it. Engineers create reliable artifacts for society that provide concrete function, usually working from a fairly precise specification. Computer science or EECS majors tend to be firmly of an engineering perspective, and so the software-creation job market is largely populated by people with this mindset. Engineers tend to be some of the most disciplined and structured software creators.

On the very other extreme are those who take the creation of software to be more akin to a creative act like poetry, music, or fine art. The exploratory and expressive nature of coding is emphasized by this camp. Interestingly, I think we have seen the most success attracting people to programming through this paradigm. Let’s call these folks “hackers.” Often the nature of the software created by hackers is discovered as the code is written, as is the case with other arts.

Between the engineer and the hacker is the craftsman, who creates a functional artifact that also has a cohesive aesthetic. Style is as important as utility, and the skilled craftman holds both to internal standards. Often, craftsmen are engaged with the actual product they are creating and are less tightly held to a formal specification, but they are still held accountable to fixed points of business value.

How is this related to pair programming? I think that the engineering camp finds most success with and affinity for pair programming for three reasons: First, engineering can get somewhat dry, so it’s nice to have companionship. Second, engineers have as their primary concern reliability, and extra eyes are great for pre-emptive bug-squashing. Third, engineers tend to de-emphasize exploratory coding. Consultancies like Pivotal Labs and Hashrocket have done so well with pair programming because they are squarely software engineers.

What is good for consultancies is not necessarily good for devoted teams, but consultancies are often brought on board specifically to instill best practices. Many of these practices are applicable to salaried teams, such as TDD, XP/agile, etc, but every time the larger community adopts a best practice from the consultancies, we need to consider if their problems are the same as ours. Consultancies, it is also essential when you teach practices to client developers to ask yourself whether the specific practices you advocate are equally applicable to full time employees. Do the same workflows and tools that work for a hand-off fixed-engagement consultancy work as well for employees that are more devoted to a particular product or project?

A prime example is that many creators of software within a company have an interest and influence on the direction of the software and are not just implementers. This changes the nature of the interaction between engineer and “client.” As soon as the engineer/client line is muddied, it is important to ask if the exploratory time that pair programming inhibits is actually productive time under some other guise. If an employee is noodling on a potential feature just to explore, that time would be hard for a consultancy to justify but might be well within some internal team-members’ responsibilities. Additionally, because consultancies charge by the billable hour, it would be unacceptable for engineers to spend billable hours exploring or noodling. In a company, the employer and employees’ interests are more closely aligned and an investment in employee advancement is more defensible.

One argument against this is that instead of noodling, employees could be pairing with a more experienced employee. This may work for some employees, but there are two problems with this: First, knowledge needs to come from somewhere, so unless the top engineers are encouraged to self-teach, there is a finite limit on institutional knowledge. Second, the experience of having made a particular mistake and self-corrected is far more memorable and powerful than even the best instruction.

The more you see the creation of software as a creative pursuit, the harder it is to justify pair programming. Anyone who has studied a creative art knows that “noodling,” “sketching,” or otherwise exploring (within reason) is essential to advancement and inspiration. Telling employees that this is not part of their job is understandable, but only by short-term valuations. I should make clear that I’m not suggesting slacking on the job is defensible, but exploring programming problems related to the problem domain or relevant technologies. As it would be ridiculous to expect a graphic designer to pair design, pair programming is similarly unproductive for a swath of programmer types.

Every discussion of pair programming that I’ve been party to has made some reference to off-the-job hacking as the solution to skill advancement and the inspiration that comes from noodling. It is my sincere hope that this will not remain an element of our young profession. Although I program for fun when I am not on the job, I do not think it is acceptable for that to be essential to professional advancement. I think this is actually less an issue for employees than employers. By relegating exploratory programming for employees’ spare time, employers risk burning out their star developers, or worse, slowing advancement.

It is insufficient to say that engineers are the only true professionals of this crowd. I’d like to avoid naming names, but would like to point out that many of the most productive and inspiring professional programmers were or are firmly hackers, and even more are craftsmen. Professionalism is orthogonal to the engineering-craftsman-hacker spectrum and must not be conflated. Professionalism is about providing the very highest quality, not a particular methodology to that end. I’m suggesting that the path of highest quality might not be the same for everyone.

Hackers, craftsmen and engineers often have the same job titles and share the same offices, so perhaps our profession needs to talk more about this. Does your workplace talk about whether the creation of software is an exploratory, creative act? Employers, are you hiring engineers or hackers? Do you make this distinction clear on your job listings and interview process? Do you expect different work patterns as a result?

The applicability of practices such as pair programming certainly it is dependent on the team and circumstances, but I’d like to frame the question in the context of what I believe to be a more fundamental question about the nature of our profession. To what extent are you a creative professional or an engineer, and do you consider this relevant to your preference on pairing?

Thanks to EAO and KGR for reading drafts of this essay.