(originally posted on the Stride blog)
Many teams at Stride pair program all day / every day. When it works, pair programming brings with it a multitude of benefits, including fewer bugs, more maintainable code, and an efficient transfer of technical and domain knowledge between team members. But it can also be exhausting (and stressful!). Here are some things we’ve found that can make a pairing session more productive:
If it’s your first time with a pairing partner, take a moment to talk about your programming background, your experience with the editor, IDE, or other tooling in front of you, and generally how you like to work. Instead of having to intuit these things throughout the pairing session, saying them out loud helps to set expectations and get both pairs on the same page.
We use a kitchen timer to limit each pairing session to a 25 minute “pomodoro.” When the bell rings, we find a logical place to stop, stand up, and take a 5 minute break. Pair programming is intense, and by forcing breaks throughout the day, we’ve found it easier to sustain a full day of pairing. Just as important, when a slack notification goes off in the middle of a pomodoro, you can happily ignore it until the break. Don’t break that flow!
Two keyboards and two monitors are critical to a sustainable pairing session. It’s nearly impossible to stay engaged if you can’t see the code being written, and a second keyboard makes it easy to jump back and forth without a lot of ceremony.
A silent pairing session is a bad pairing session. It can feel a little weird at first, but thinking out loud is an important part of pair programming. The only way to really collaborate on a piece of code is to talk to your partner. If you are sitting silently while your pair types away, don’t be afraid to interrupt and ask them to explain their thinking.
One of the key benefits of pair programming is the immediate code review, discussion, and refactoring that occurs around a piece of code. But be mindful of gold plating and working a problem way beyond the point it adds value. At some point, you need to agree the feature is done, commit it, and move on.
Following these five steps will ensure your pair programming experience is a good one—and possibly something you’ll look forward to doing again.