Pair Programming tips


#1

Hey y’all! I’m curious what everyone’s experience with pair programming is.

Do you use it? What kind of techniques do you use? How to you manage pairs with different skill levels?

I’ve enjoyed the “ping pong” approach in the past (person A writes a test, person B writes the implementation to make it pass, repeat). I’ve also been reading about a more metered hourglass approach where you just switch role every ~5 minutes. Interested to try this out and see how it works.


#2

:wave:

The “ping pong” approach is fantastic when you build something new. I find it quite hard to use when you change something that’s already in place. It works really well for Unit Tests. For integration tests, you might want to switch pairs as you change layer. Ex: When building a JSON API, you can switch driver when you change controller / model / service / serializer etc.

Changing role every 5 minutes or so work as well. I think it’s important to understand what your role is as a driver and navigator. This gist provides pretty good guidelines.

As you mentioned, pair programming is different when one of the developer is more experienced. The person that’s more experienced gains a lot from having to explain why she suggests to do things a specific way. In my experience, both learn a lot in the process.

I believe that it’s good to not pair-program all the time. There are “creative” explorations that you might want to do on your own without having to justify every line you write. It can also be more efficient to have the engineering team explore and agree on architecture (and naming!) before one developer implements than making all those decisions while pair-programming.


#3

I’ve enjoyed the ping pong approach to. It makes it very easy to stay engaged.

When I’ve paired with backend developers who are learning to implement a frontend, I’ve used a teacher/student approach. I’ll drive while implementing the first section of work until completion, while guiding them through my thought process and encouraging questions. They’ll do the next section while explaining their process. If a mistake is made, we work through it together with the goal of helping them understand what causes a frontend bug like that.

If the issue is small, it might span a couple issues.


#4

The hardest lesson I learned was actually in school way back when. Don’t touch the keyboard. When you are trying to help someone or explain concepts. You can’t touch the keyboard and just take over when its frustrating (I’ve had a few exceptions when I am trying to describe a quoted string, or a way off topic example to quickly highlight a discussion point). You need to slow down and explain what and why you are doing.

The other person absolutely needs to be comfortable saying “stop” and “slow down” and “why?” and other questions. If they can’t do that, its pretty much like telling them what to do and not that productive. I mean you also need to learn to slow down and explain, but they need to be comfortable too.

But these have been more my experiences with less experienced based mentoring pairing. I don’t think I’ve done much regular pairing outside of frantic fire fighting, but by then I usually pull out my own computer and dig in my own way.