A couple of weeks ago I got together with some friends for dinner. We had a bunch of vegetables, a big piece of steak, a grill, and some vague plans. Within moments, we had divided up the tasks and started working in four parallel tracks. One of us started preparing a bowl of tomatoes and onions to be grilled first (for a salsa brava), one of us took over starting the grill, one of us started seasoning the steak, and the last started cutting up and staging the vegetables. When the two of us with shorter tasks (tomatoes and steak) finished them, we switched over to general vegetable preparation.

I love this kind of thing. It reminded me of the best parts of my time at Pivotal, and why I'd loved that job so much. On-the-fly, just-in-time, leaderless collaboration is one of my favorite parts of being a person, and I really value the skills I have that make that possible. While I've definitely struggled with pairing when my pair didn't have these skills, working with people who are good at pairing is great.

What does it take to be "good" at pairing?

We had a clear goal (dinner) that we all valued and all the necessary materials. We all had the ability and habit of "talking out loud" in a particular way that supports group decision-making. We all were able to take initiative without crowding each other, and to check in on each other.

These are intermediate-to-advanced pairing skills. This article describes the key skills required to be a good pair, a pair who is productive and rewarding to pair with for most people. I expect most people who are new to pairing to develop these over about two years in a pairing-heavy environment. However, many experienced pair programmers don't have these skills, or don't consistently apply them, especially the later skills.

Identify your goal

We had a clear goal, and one that we all valued: Dinner! We had similar definitions of what would make "a good dinner," and we all enjoy cooking individually. We'd gotten together to share that experience, and to show off a bit.

"Keeping track of what you're doing and why" can be a surprisingly hard job in other contexts. Software engineering presents all kinds of distractions. The first foundational skill is just to keep track of your goal at all times.

This is part of the reason that pairing so often goes together with test-driven development, and with a particular set of project management practices. Breaking tasks into relatively small pieces ("stories") with clear external checkpoints ("story acceptance") makes the job of remembering what you're doing easier. Using tests to guide development helps to break down tasks even more, because at any given moment a pair's goal is usually "make a test pass." Context about the person who will ultimately buy or use the software, and what goal they're trying to accomplish, helps keep the pair clear on "why," which avoids distracting or demoralizing conversations.

If you have these supports, you may not have to do much work to keep your goal clear. Without them (or in situations where they aren't sufficient) you'll need to do this yourself. Writing tasks down can help, as can getting into the habit of discussing with your pair what you want to get done as you start the session.

Say what you're going to do

While we prepared vegetables, seasoned meat, and ran the grill, we verbally inventoried the necessary tasks and announced which ones we'd each take over in turn, which left the remaining decision space clear for other members of the dinner mob. As we worked, we reported any ideas or discoveries, and adjusted our plans and timing accordingly.

While it's possible to pair without "thinking out loud" – I've seen pairs work for hours just by passing the keyboard back-and-forth, communicating intent by writing tests – typically pairing involves a lot of talking.

Say what you're going to do before you do it, and say why.

"I'm going to take start on the steak because we should grill that first, we can grill the vegetables as it rests."

"I'll start prepping the tomatoes and onions because I'll need to bring those back inside to finish them before we finish grilling the rest of it."

"I'll handle the rest of the vegetables since it looks like there's nothing more specific I should be doing."

The "why" is key. Knowing "why" helps your pair stay synchronized with where you are, rather than trailing slightly behind you. It also helps them bring unexpected ideas to bear, since they can point out things that might help you accomplish your underlying goal, not just things related to the specific task you're implementing.

Take initiative

That dinner worked because we all responded to uncertainty – a general task but no specific instructions on how to accomplish it – by starting to do things. "I'm going to..." "I'll start..." "I'll handle..." We listed the tasks that there were available to do but we didn't stand around waiting for someone to tell us to get started. We picked things, or we offered choices to each other, and acted on those choices.

Folks who are new to pairing sometimes wait for permission or approval when pairing. This can make them especially draining to pair with; the "lead" pair has to "drag them along." I used to have this problem myself, and one of the best pieces of advice I got for it was that if I didn't know what code to write, to write pseudo-code – to write something. Even the wrong idea is better than no idea, because a bad idea can be improved with feedback. A bad idea will at least generate more information when it fails. A team working on an idea tends to generate more ideas. A team that's sitting just sits.

Leave space

Once you've gotten the hang of taking initiative, you'll need to keep an eye out for its counterbalancing problem: Taking over the pair and not leaving space for your counterpart. Since the point of taking initiative and talking out loud is to get feedback fast, you need to also give your pair time to hear what you're saying, process it, and respond to get the full benefit of working as a pair.

This starts with "switch who's running the keyboard regularly" but it goes deeper than that. Leaving space means leaving time: Time for your pair to process information, formulate questions, and understand the issue for themselves. Time spent not doing, time spent listening, time spent waiting. This can be difficult, and it's not something most people have much practice with. It's not something our culture generally values.

If you're having a find yourself telling pairs to "grab the keyboard more" a lot, you may need to do some hard introspection. If you value yourself by how much you can get done in a day, sitting and waiting while your pair builds their own independent model of a problem you already understand will be disorienting, even painful. If you value what pairing brings you, you need to understand what your ego needs, and how to get it out of the way, in order to make room for your pair.

Pay attention to your pair

Learning to leave enough space is probably going to require developing the fourth basic skill of pairing: Paying detailed attention to another person while working and talking. This is very hard, and can take a lot of energy.

Is your pair paying attention to you and the problem, or are they checked out? When did they check out? Are they confused? Bored? Distracted? What's their model of the problem that you're working on? Does it match yours? What are their goals right now – to complete a story? to learn more about a particular problem? to practice a particular skill? – and do they align with yours?

The answers to these questions will tell you when to slow down and when to speed up, when to say more and when to say less. Synchronizing your pace with your pair will maximize the idea quantity and quality that the pair generates and executes. It'll also make the experience more enjoyable for both of you.

If you're not already good at non-verbally or implicitly monitoring your pair's state (I wasn't), it helps a lot to ask explicitly. Be warned that some people will be surprised by this, especially if you're very blunt. This is one area where the sheer volume of social interaction that pairing a lot can give you will help. Over time, trying different ways of asking people how they're doing, and paying close attention to how they react, will teach you a bunch of specific techniques and when to apply them.

Manage your own feelings

As you start to get good at tracking your pair's state, you may be tempted to start managing those feelings. I struggled with this for a long time and it was a big part of why pairing was so exhausting for me, and got more tiring over time rather than less. It's best if you can avoid this temptation, and focus on being aware of your pair without being responsible for your pair.

Instead, use that energy for a much higher leverage problem: Your own feelings. Work can be frustrating and boring. It can provoke anxiety. You have a life outside of work, and may be bringing all kinds of feelings about that into your pair. Pairing can magnify all of those feelings, especially if you start reflecting you and your pair start reflecting each other's feelings and "resonating" – hyping each other up about a thing that you're both scared or mad or frustrated by, or the reactions that you're having to each other's feelings.

Exactly how to do this is somewhat outside the scope of my own expertise. Therapy, meditation, and reading about the mind and the human experience have helped me. Learning about my own emotional and social needs and modifying my life to satisfy them has also helped me keep an even keel in professional situations. (Wanting to be more in control of how I expressed my feelings is ultimately why I developed a systematic approach to making friends, for instance.) It took decades for me to hit on an approach that worked for me, though, and what works for you will likely be different.

As a general rule, though, don't vent to your pair. A little bit of emotional sharing can be helpful for setting those feelings down during the pairing session, but this is a person who's stuck with you for many hours a day, and not entirely by their own choosing. They're not a therapist, and they're not (necessarily) a friend. They're a pair.

Feedback

If you've spent a lot of time pairing, and you see something here that you disagree with or that I've missed, I'd really appreciate it if you'd send me a note to my e-mail address, nat at this-website. This is based on five years of experience and conversations, but that's still a very limited set of information.

Hiring, etc.

Another Ruby on Rails developer job this week, at Backerkit. Pair programming and a San Francisco office, but if you're looking for a Pivotal-like in-person environment this might be a great role for you.

If all-remote is your jam, a team on the GitHub Platform team that pairs is hiring both senior and non-senior engineers.

Checkr is hiring a bunch of roles, and practices both pairing and TDD.

Jobs from past issues of this newsletter

Some newsletter stats

I had a second article make it to the front page of Hacker News this week (though not #1, alas) so I thought this'd be a good moment to share some stats from my ongoing project of building an audience I "own."

I've been publishing weekly for about four months. This post will be my 19th article. When it goes up, it will also be sent to 107 members. 111 people have signed up over the lifetime of the newsletter. I have about a 55% open rate, so I expect it to be read by about 58 people by e-mail.

Over those four months, Google Analytics has record 21,000 total users and 27,000 total views. About 21,000 of those views were to "The Mortifying Ordeal of Pairing All Day." Another 2,200 were on "Lessons Learned from 5 years using Pivotal Tracker." After that, most posts have gotten fewer than 100 views on the website. The exception are the two posts I wrote before "Mortifying Ordeal," which picked up some traffic from folks browsing around while that was going viral.

I've picked up over 8000 users from Hacker News directly, and another 8000 "Direct" that I suspect were also largely Hacker News referral traffic. About 1500 users have come from Twitter. Hitting #1 on Hacker News was responsible for the majority of the remaining traffic, because it got picked up by various automatic aggregators.

I also, however, have received about 200 organic search hits, and the rate there has increased over time – I expect to see at least twice that traffic over the next four months. The main articles that have done well in search are "A Close Read of the ActionDispatch::TestResponse Class," "Rspec Feature Tests," and "The Mortifying Ordeal of Pairing All Day," though my Pivotal Tracker article has started getting more search impressions since it got linked by Hacker News. Earlier this week I got six whole clicks, a new daily record.

According to Google, I have about 353 external links from 110 pages, but I know there are links it hasn't counted (yet.) The vast majority of those links are to "Mortifying Ordeal," again through the magic of automatic aggregation.

Before last week's traffic spike, I'd been seeing between 5 and 40 users per day, and somewhere around 100 users a week. On Sunday, I saw about 1600 visitors. That's dropped off – yesterday I saw 17 users – but I expect to see a small increase to the steady-state, between the extra link juice to organic traffic, and direct referrals as folks continue to see the Tracker post and share it to social media and with their coworkers. That was generally the pattern I saw back when I was running a tabletop roleplaying blog – big spikes would leave behind an ongoing stream of traffic, and over time that adds up.

While I had hoped to have more like 500 newsletter subscribers by now, I have dramatically more backlinks than I expected, and I'm quite pleased about that. I also feel reasonably confident about my ability to write things that people find valuable enough to share, and to subscribe for. I've identified at least three niches (deep dives into Ruby details, process tooling advice, and personal essays about software-related experiences) where there seems to be overlap between "what I enjoy writing" and "what the internet is interested in."

Literary appreciation

We're onto The Robots of Dawn in our household's re-read of Asimov's robot detective novels, which reminds me to note that those novels influenced my piece last week on career ladders. Everyone in those novels is always going on about their Classified Rating (C6, C7, etc.) and the little privileges they afford, and I think this is supposed to sound deeply weird to an American audience, but it also sounds exactly like how managers I've known talk about performance evaluation.

My partner keeps trying to read me To Be or Not To Be. I don't like it, but he does, and you might. I chose to be Hamlet's father('s ghost) and to take matters with Claudius into my own, er, semi-corporeal form.

We've also started playing a bit of Torchbearer, which is quite possibly my favorite roleplaying game. Its main competition is Original D&D and its retro-clones, which tells you something about what kind of nerd I am. Torchbearer is probably better than OD&D at reliably generating the kind of resource-constrained, strategic, lateral-thinking problem-solving dungeon delving that I like best in a tabletop game.