By William Hertling, HP 3D software developer and science fiction writer
“Pair programming” sounds so simple. Two people sit down together in front of one computer and write code.
Easy, right?
Except sometimes it’s not.
Ah, the drama of pair programming. Arguing over what needs to be done. Fighting over how to do it. Bickering over coding style or test completeness. Resenting the other person for getting distracted.
My coworker, Melanie, once observed my friend Mike and I programming, and she said we fought like an “old married couple.”
For a long time, I accepted that the repetitive process of disagreement, discussion, and eventual agreement was a normal part of pair programming. With some pair partners this would be difficult, and with others it would be easier.
Then I paired with a coworker who was very brilliant and passionate, and left me utterly exhausted every time we paired. We spent far more time arguing about how to do something than actually doing it. We’d argue over practically everything. Each time we’d finish one squabble and actually write code, we’d get as far as the next test or the next decision point, and then have another heated debate over the best path forward. Actual progress was excruciating.
I grew to dread our programming sessions. And yet, here was this intelligent person, who was clearly an asset to the team. Pairing together wasn’t working, but not working together would mean not getting to benefit from their expertise and insight.
There had to be a better way.
Setting the ground rules
There are no couple’s therapists for pair programming partners, so we had to figure out a solution on our own. What we discovered is what I came to call coding negotiation.
I looked at the sources of our disagreements, and realized that we would often have fights and discover only at the end that we both wanted the same thing. Or that we’d be arguing over something and actually only one of us cared about it. What I realized is that if we established a common ground before we started coding, then the actual coding would go more smoothly.
Up front we needed to have a conversation about values, work practices, objectives, and personal needs. They should be discussed in that order because fundamental items like values will trump less important items like objectives.
Here, in order of importance, are the elements of a good coding negotiation:
-
Values
Values can trump almost everything else, so it’s important to discuss them first. How we approach other topics may depend on understanding each other’s values. What values are important to each of us? Do we value creating quality code? Readable code? Highly efficient code? Well documented code? A superior user experience? Clever programming?
If we understand each other’s values, then we understand the perspectives we bring to coding. If delivering an awesome user experience is a core value for my partner, and we disagree over how a page looks, I know that they are advocating in pursuit of their core value.
Then there are a few possibilities:-
If we share a core value (as we usually do), we only need to figure out how best to deliver it. The discussion usually goes smoother when we know that we’re both trying to do the same thing.
-
If my partner’s position is important to them, but not at odds with any of my core values, I can just let the issue go and let them decide.
-
On the rare occasion when it’s at odds with one of my core values, we need more discussion.
-
-
Work practices
How we work is an important element of working smoothly together. Do we learn by doing or by studying? Are we going to allow each other to have phones present? How frequently are we going to take breaks? How long are we working together? Are we ping-ponging (alternating specs and implementation) or taking some other approach? Is it okay to joke and have fun?
Two people that have compatible work styles or that have grown to know each other’s work habits over time will naturally fall into a functional pattern of working together. But for people who haven’t paired, or who pair only occasionally, it’s beneficial to get onto the same page. Otherwise, resentment builds as one partner wonders when they’re ever going to get to go to the bathroom, or why it seems like the other person isn’t paying attention because they’re texting, or just how many different web pages that person needs to read to decide on which library to use.
Just as in romantic relationships, resentment between two pair programming partners will turn into arguments that mask the real problem. One person will pick at a line of code when what they really want to say is “put the phone down and pay attention.” As they say, when couples argue about the dishes, it’s never really about the dishes.
When two people have different work styles, compromises are necessary. There is no one right way to program. One coworker may hate that the other texts, but allowances have to be made for different preferences and personalities. Maybe they can agree on a ten minute texting break every hour.
Agreeing to a set of compatible practices reduces resentment and needless argument, and keeps both people happy and productive.
One core discrepancy in work styles is how laid-back versus achievement-oriented each partner is. Partners at opposite ends of the spectrum may have a difficult time relating to each other. For the more gung ho partner, recognize that a reasonable compromise that keeps your more laid-back partner happy and supportive will be, in the end, more productive than an aggressive work approach that makes them angry and combative. For the laid-back partner, recognize that a compromise that keeps your more achievement-oriented partner happy, will lead to a more easy-going day overall.
-
Objectives
Exactly what are we trying to do? In an ideal world, a story or feature request is so clearly, perfectly, and yet succinctly articulated that there is no ambiguity over what needs to be done. Since that has never yet occurred in the history of programming, expect that after you and your partner align on values and work style, you’ll also need to go over the story to determine exactly what the objectives are.
How will you know when you are done? What are the tangible deliverables? What is good enough for the request? What other unstated objectives might be present in someone’s mind? (“I know this story says implement the new customer feature X, but really I see this as a chance to refactor the Customer model and address that lingering technical debt…”)
Again, the purpose is to surface all the information that will be necessary for decision-making as you are coding. When one person thinks they’ll be writing a few lines of code, and another person plans to install a new library and refactor the model, that’ll be a much smoother discussion if you understand the why behind each person’s point of view.
-
State your personal needs
It’s perfectly fine to have personal objectives as well, as long as you make them explicit. I’ve seen many cases of people making a technical argument for a particular choice point when they really wanted it for a personal reason. Maybe they think a particular library is cool. Or maybe they don’t want to refactor that code right now because they want to go for a walk while it is sunny. Unfortunately, rather than being up-front about their personal needs, people will sometimes avoid vulnerability by trying to make a technical argument for what they want to do.
But going down the technical argument route leads to a time-consuming, energy-draining and ultimately needless debate over merits. We might as whether argue over whether the Enterprise-D can beat a Star Destroyer. It’s better to simply say “Hey, we should use library X because it’s cool”, rather than surreptitiously arguing : “We should use library X because it’s more efficient.”
In summary, align on shared values first, then decide on work style. Discuss the objectives and deliverables, including any personal needs or goals that have been left unstated.
Throughout this preliminary process and while coding, you will need to negotiate and compromise. When you come to a decision point, if it isn’t actually important to you, don’t be afraid to let the other person make the decision. Conversely, when it is important to you, feel free to say so. There is a give and take, and not every choice point needs a debate to find the technically superior path.
Two impassioned individuals may spend an hour or more engaged in coding negotiations before they ever touch a keyboard, but the payoff will be a harmonious, efficient, and productive coding session.
Not like this...
William Hertling is a web strategist, software developer, and science fiction writer. When he’s not coding, he writes novels about serial killers turned startup entrepreneurs (Kill Process) and runaway artificial intelligence (Avogadro Corp).