The absolute best code I’ve ever written was when I’ve been most compatible with my pair.

It wasn’t that long ago, and I was relatively green as a pair. We wrote Backbone code -- lots of it -- on a high pressure project, working overtime consistently to meet a deadline by the end of the month. It was do or die for the project and I was ready to write code. But my pair didn’t seem that rushed.

He took his time, sat back and asked my opinion like an equal. I responded in kind. He never rudely interrupted when I coded. I never rudely interrupted him. Sometimes I went off and coded a part on my own, and sometimes they did the same. But we both had the flexibility to bend to the ebbs and flows of each others styles and dispositions on any given day.

Even though the pressure was on, my pair helped me keep my cool simply by keeping theirs. And the code we produced wasn’t just on time, but was some of the best code in the project -- incredible test coverage and abstractions that stood a number of changes in feature requests and extensions.

And it was fun. Sprinting to hit deadlines shouldn’t be fun. But it was. I have never written such good code, and had such fun doing it than when I’ve had a truly good pair.

Talent is not an excuse

The art of being a great pair is something that is known to be a key component to building a great software team and delivering software but rarely worked on, or critiqued in favor of individual satisfaction and heroics in programming. Pairing is one of the most valuable tools software teams can utilize to produce better software in less time. But I commonly see more weight given to individual heroics and smarts. If you’re smart, all is forgiven.

The individual should not be praised, or forgiven for being a worse pair because they are a more talented programmer than the next one. Programming is a team activity. Building great software is a collaborative effort. Pairing well is one of the most important things we can do to facilitate that.

Being a mediocre programmer but a great pair will create more value to clients and systems than being a great solo programmer but a weaker pair.

Are you a good pair? Have you thought much about it? I commonly see these traits in bad pairing sessions:

• judgement about design/implementation in a malicious way, either after you’ve written code or during
• also in a joking way (but with linings of the truth -- mostly because the pair feels insecure about what’s going on in the code and is unable to control his feelings) This can happen before, during or after coding.
• non-constructive questioning or comments while implementing
• jumps in and interrupts your turn to type something
• seemingly hovering over me to start typing something -- lack of patience
• starts to implement their ideas without discussion, or minimal amount of discussion

Emotional Maturity and Immediate Gratification

Everything above lacks three major traits often lacking in a pair: empathy, humility and patience. Many programmers lack emotional maturity. Like a child, if they want something they make noises or joke; if they are tired and frustrated, they will whine or insult; if they jump ahead without consideration, they are undisciplined. Its a problem with immediate gratification, instead of showing emotional maturity in favor of collaborative cooperation.

Don’t write code...yet

Before you write even one line of code, set a tone of equal understanding, patience and cooperation by discussing potential design decisions and implementations for the story. Don’t rush, and be more concerned with the quality of the discussion and ideas generated than on finishing the next line of code.

I've had pairs that have brushed this off and plowed ahead with their own ideas. I’ve also done this myself. This usually leads the pair to feel unwanted and unneeded. It also makes it harder for the pair to contribute creatively if both programmers have separate ideas of how the design could play out.

This may not be immediately visible in the beginning of story work, but the fractures in design communication will grow more serious and ultimately an inferior product will be produced.

Care about the success of your pair

When your pair is coding, make sure you care that they are in a good state of mind and working well. The quality of the end product is often a reflection of the psychology of the people working on it. If your pair is upset, confused or angry, offer to take a step back and relax.

When they are working on a problem, don’t sit there like an observer of chess, ohh-ing and ahh-ing when you see a different way to solve a problem. Sit and show that you are observing, checking, but ultimately a safety net that doesn’t judge your pair. If a pair feels like, even in a joking way, that they will get rushed, criticized for a mistake or flawed piece of logic, they’ll be more nervous and won’t work as well.

This takes a lot of empathy, and is something that most programmers don’t realize.

If you see a different way to go about something, reveal your ideas through questions to your pair in a non-condescending way. Help them see your point of view in a direct manner. Help them patiently assess the use cases the code could be tested against. But never treat them like a school child.

While you code, ask them the same questions when you come up against it. Bounce ideas off of your pair while coding. Never see your turn in a pairing session as an opportunity to compete, prove something or show dominance as a programmer.

I’m not saying don’t try clever things, but do it as a team transparently; with as little ego as possible. Building trust and bridging communication will help you and your pair work as a singular unit. And that is a relationship that delivers truly amazing code.

Being a good pair means managing your ego and emotional maturity

A lot of programmers became programmers because they loved to program. I once read somewhere that a programmer keeps programming because one day they solved a really difficult problem and felt amazing. Now they are chasing the dragon, coding just to find that feeling again.

I’m also familiar with the joy of solving a problem on my own. But its important to realize that if we are to mature as builders, building becomes less about personal triumphs and more about team triumphs. Programming is not a solo game anymore. And pairing effectively means that you don’t come first anymore -- the end product and your teammates do.