Practical Pair Programming

A second brain helps you give good names to classes, methods, and variables and write clearer documentation. It gives the pair enough headroom to think about architecture, apply helpful design patterns, and sometimes even come at a problem from an entirely new angle. It means you’ll think through more edge cases in your business logic and have twice the empathy for users as you design how they’ll interact with your software.

Sometimes you spend too much time digging into a problem that doesn’t really need to be solved right away. Your pair can help you see when you’re getting in the weeds and excavating pointlessly.

When your estimates are too optimistic or you feel guilty for having gone down a particularly deep rabbit hole, you may be tempted to make up for lost time by skipping the writing of tests, implementing only the happy path, or not giving attention to security. Your pair can be the angel on your shoulder, reminding you to do what’s right.

if you can’t get a pair or you’re looking to start with a few baby steps, these are some alternatives that are better than nothing. Having someone talk through a problem with you for fifteen minutes before diving into a solo task can be enormously helpful. Sometimes a brief conversation will save you days of building something the wrong way. “Rubber ducking,” or talking something through to understand it better, is another thing we sometimes do in our office. Even if the listener has little knowledge of the problem domain (or happens to be a yellow plastic bath toy), just articulating it can help solve the problem.

tasks that are a poor fit for pairing: Research, reading, chores like manually converting templates between languages, and lots of copying-and-pasting.

If you make a mistake while soloing, it should be the sort of tactical defect that’s caught by your test suite, compiler, or linter. If you’re producing strategic defects (going down the wrong path), then you should get back to pairing.

You might also trade control by tying each turn to a cycle like that of test-driven development (TDD). Under TDD, you first write a test for the tiniest change in behavior, watch it fail, then write the minimum code that makes the test pass. You next take the opportunity to refactor the production code and the test code, and only then move on to the next small change in behavior. “Ping pong” pairing, as Ward Cunningham describes it, simply alternates who writes the test and who makes it pass. After perhaps many iterations, you will have satisfied all the acceptance criteria for the story and can consider the feature done (http://bkaprt.com/ppp/02-03/). By working in this fashion, you ensure that both of you not only have equal time driving, but you get to challenge each other to only make small changes to the codebase, have the test suite passing after every change, ensure high test coverage, and collaborate on refactoring at each step.

When you feel comfortable in your pairing environment, check in with your partner rather than assume that your feelings are shared. If you’re part of a dominant group, be it according to gender, race, or another characteristic, remember that people in underrepresented groups often find it risky to voice concerns that fall outside of the lived experience of their colleagues.

Malcolm Gladwell pointed out in Outliers: In commercial airlines, captains and first officers split the flying duties equally. But historically, crashes have been far more likely to happen when the captain is in the “flying seat.” At first this seems to make no sense, since the captain is almost always the pilot with the most experience. But…planes are safer when the least experienced pilot is flying, because it means the second pilot isn’t going to be afraid to speak up.

There should be a dialogue running almost continuously. The driver (the one controlling the keyboard at the moment) is constantly thinking out loud in a practice called “reflective articulation,” which helps the navigator (the one not typing) understand what they’re doing and keep up with what’s going on

The navigator should be acknowledging the driver’s narrative, filling in the gaps, questioning their choices, noting potential problems, helping remember what that thing over there was called, and helping direct where to go next.

An important job when you’re the navigator is to provide a “subliminal process check” and speak up when you think you’re working too long, trying too hard, or going too far on a task. Try questions like, “Is this something we should spend more energy on, or is it good enough?

A beginner exposes where the code doesn’t adhere to the Principle of Least Astonishment (POLA), which is when a piece of code does exactly what you’d expect it to do from reading over it.