Pairing and the Dual Nature of Programming

When I'm coding alone, I tend to write pretty sloppy code because I'm just so focused on the feature that the code quality takes a back seat.

When I take a step back in the middle of feature development to clean up my mess, I find I've kind of lost track of the "big picture" a little bit. It's like the code becomes the product and my brain forgets about the real thing. This makes it harder to think of all the edge cases, or how the feature relates to the whole product.

I'm either thinking about how to write the code, or how to build the product. It's hard to switch back and forth without losing good ideas for both in the friction.

Of course, as you get more experience, somtimes good code can effortlessly roll off your fingertips. On some tasks I can code for hours and be happy with the result. But other times, I know I'm making a mess, but I just don't want to stop the "product flow" that's happening in my brain!

I've had very little experience with pairing in my career--pretty much just helping co-workers debug some weird JavaScript thing for an hour at their desk. But when Michael and I started building Remix we paired 100% of the time for many weeks.

Zoom was like our office. We'd show up each day. He'd share his screen and ask "what are we doing today?". Then I'd start talking about the features I thought we should work on. I can't speak for Michael, but I loved the arrangement 😂

I found that when I wasn't typing out the code I was able to stay in "product mode" the whole time. We'd figure out what needed to happen, Michael would start banging out some code, and then I'd start thinking about all the edge cases, all the things we hadn't considered yet, and what other features we had on our roadmap that the current work might also be affecting.

Then the person writing the code can stay more in "code mode" and be thinking about how the code fit together, how it might change in the future, how to compose with existing stuff, etc.

Of course, I often had ideas on how to implement the code and Michael had plenty to say about how the feature should work, but it felt like we each got to lean slightly one direction.

(On that note, it's important that the person who isn't writing the code just chills out about the actual characters being written. "Maybe use a reduce instead of loop" is just irritating and pointless, but strategic things like "wait a sec, can we persist this with location state instead of memory?" is useful.)

Because many programming tasks have this dual nature, and switching between them adds friction for an individual, I think pairing leads to better products and better code with more efficiency than the two people working separately.

Give it a shot!