Advice for pair programming that you'll hate

So you’re stuck watching your pair do things. You don’t understand what’s going on, and you can’t seem to get enough of a handle on the problem to be able to contribute. How do you get out of this situation?

Advice for pair programming that you'll hate
Photo by Clay Banks / Unsplash

Hey newsletters. I'm Nat Bennett, and this is Simpler Machines, a newsletter I still don't think I have a good way to describe. "It's about software, I guess?" is the closest I've been able to come. Something something good design, maybe?

If you have a better description, send me an e-mail. I'd love to hear it.

Stuff on my mind this week

  • Elixir and why it's such a delightful language
  • Ted Lasso
  • Programmer productivity and why it's important to get faster
  • A trip to Point Lobos & Monterey I'm taking next weekend (sign up for the pop-up newsletter, it'll be fun)
  • California history and the f/64 society
  • How stories we tell about ourselves get in our way and why we keep telling ourselves those stories anyway
  • Where to get some black loose leaf tea

This article is solidly in the “advice to my younger self” category.

So you’re stuck watching your pair do things. You don’t understand what’s going on, and you can’t seem to get enough of a handle on the problem to be able to contribute. How do you get out of this situation?

I’m aware of at least three solutions, and if you’re having this problem a lot I don’t expect you to like any of them. You can:

  • Get more aggressive
  • Get better at programming
  • Lower your standards

Get more aggressive

This is the least interesting piece of advice here because it’s the advice you’ve probably already gotten. “Just grab the keyboard!” was advice that I got a lot when I was pairing. “When you have an idea, just do it!”

It was infuriating, because a lot of the problem was that I didn’t have ideas. I could track what was going on well enough to follow along, but not to formulate ideas about what to do next. As soon as I’d gotten to the next step, my pair had already moved three steps beyond me.

It felt really unfair, too. My pair was more senior to me, more experienced, more aware of how to approach the story, more powerful socially within the organization. Probably made more money. Often, they would give this advice as they admitted that they were “a bit of a keyboard hog.” And yet somehow it was my fault that I wasn’t driving enough?

It was unfair, and it is unfair, but it’s also true. If you’re confused because your pair isn’t “giving you” enough time to figure out what’s going on, they’re not going to start giving you that time on your own. You need to start demanding it.

Get better at programming

Again: You’re going to hate this advice.

But one of the things that’s going on is that you’re a much worse programming than your pairs.

Not in all ways. You might be better at design, and at testing. But the basic act of typing in lines of code and getting them to run? You’re worse at that in a variety of ways.

You don’t know the language itself as well. You have to look up basic stuff like for loops. You don’t know the libraries. You don’t know the frameworks. You haven’t written nearly as many tests, and you haven’t solved nearly as many problems, so you don’t have as much “oh yeah that’s just like…” templates available in your head.

The only solution is to write more code. (Or config YAML, or Terraform, or whatever it is that you’re writing.) Write more code in general, and write more of the specific kinds of code you’re writing with your pairs.

Lower your standards

A big turning point for me in my programming confidence was this day that I spent completely confused, the entire time.

At the start of the day I negotiated a little bit with my pair about how we were going to approach the work. We needed to fix a tricky security vulnerability, and we needed to do it as fast as possible. I didn’t understand the problem yet. I was also much less experienced with the programming language we were using. It was going to take at least a couple of hours for me to get up to where my pair was, and remember, tight deadline, nasty security problem.

So I said, basically, don’t worry about getting me all the way up to speed. Start working, and I’ll do my best to follow along, and if I get really confused I’ll stop and ask questions.

I spent pretty much that whole day going, “Huh?” And, “Wait, why are we looking at this class now?” And “Hang on, what were we doing again?”

At the end of the day my pair turned to me and said, “Wow, that was a really productive day of pairing. You really helped keep us on track and focused. Thank you.”

I realized then that I could contribute a lot even without a complete, detailed model of what was going on. That the trick was to focus on contributing, not on comprehending, and on being willing to engage even when I was confused.