by Chris Erin on December 13, 2016

Two Keyboards, Two Mice, One Monitor. This is a little bit of what pairing looks like in practice, constant discussion, trials, rollbacks, re-thinks all looking for a best solution. An all-day coding marathon every day that reduces unwelcome pauses in momentum.

Agreements are the lifeblood of pairing. What to work on, how to work it, what to name this, how to solve that, a pair has to agree on everything. If a developer is making decisions without explaining those decisions, without asking for input and without expecting input, then it's not pairing, its soloing. Agreements are everything.

Not all agreements are easy! The time it takes to reach an agreement corresponds with the difficulty of the problem you are trying to solve. But that is where pairing starts to shine. With even moderately difficult problems, pairs discuss the different trade-offs in a joint search for the most elegant and simplest solution. Its a discussion of how things work that might necessitate some research, or a different perspective from a co-worker. If you can agree on how things work (not as easy as it sounds) that creates a platform for solving the problem.

Pairing works well when both developers are thinking about the same narrow problem set at the same time. The way Hashrocket collects and writes requirements leads directly into writing an automated test that describes a very particular user experience. We focus on one user experience at a time, and writing the automated test for that user experience leads us into writing the code necessary to realize that user experience. This is test first development.

Test first development always starts red. It always starts with a failure, and that's always the first problem you need to solve. And then there's another failure, and another failure and another. Each test provides a goal and each failure is the next step towards reaching that goal. This is incredibly important in pairing as it provides the focus for the pair to think about the same problem at the same time. Without it, each developer will naturally start thinking about different aspects of the system and different use cases. When we lose focus, we lose momentum. Test first development helps guide a pair from the first step to the last and when you're done you have a green test, code to deliver and a victory to celebrate.

It's amazing what kind of energy pairing brings out of both developers. For a pair the day starts with a discussion of how to proceed. And once coding starts, it doesn't stop. It's very rare for a pair to not know what to do next or to become blocked. If I don't have the next line of code at my fingertips, my pair does, and vice versa. Maybe because it's easier to think about the next step when you're not typing, or its easy to think about the implications of what's being written as its being written. And when as a pair you reach a point where you don't know what to do next, well, that starts a new discussion!

When I first started, this constant discussion about what to do and how to do it wore me out! I would come home exhausted every single day in a way I hadn't experienced since I worked in a greenhouse picking lettuce as a teenager. Over time I got used to it, developers can build up a tolerance for communication and structured decision making.

Having one set of hands on the keyboard at all times frees the other set of hands to take care of other tasks without stopping momentum. Throughout the day we communicate with stakeholders, ask other developers questions and check-in with our project manager, all of which can occur while still developing. Searching for technical answers on the internet is another thing that can be done concurrently. I can look through the Rails docs to determine what obscure arguments of obscure methods do while my pair focuses on the programming task at hand.

Being able to do two things at once has obvious time saving benefits, but the greatest benefit is maintaining context on a particular problem. Tough problem sets involve many different variables and loading those into your head is part of solving the problem. When pairing, there is less risk of losing the problem set (a phenomenon called context switching) when engaging with a different problem. This enables us to solve problems faster and be responsive communicators which helps our team members do their own jobs better. Pair multi-tasking enables to maintain focus as a whole.

This is what its like to pair program on a regular basis, I hope it provides some insight into how pairing works at Hashrocket.