608.620.5104 | info@tenforward.consulting

A Guide to Effective Pairing in Tech: Senior Pair Edition

By Hilary Stohs-Krause
Published September 16, 2019


I recently gave an internal talk with Ten Forward's VP of engineering, Brett Samson, on pairing best practices. We pulled from our own combined 13 years' of experience, various conference talks I've seen, and a recent Twitter conversation. 

Here's a written version of what we discussed, looking at pairing from the senior point of view; later, we'll explore pairing as the more junior person.



Kate pairs with ALL the Ten Forward seniors. 


  Pair with a Purpose

Before you begin pairing, think about what you'd like to get out of the session. It doesn't have to be super-specific, but we find that spending a little time at the beginning to set expectations can go a long way toward ensuring both parties get what they need or want.

For example, maybe your goal is among the following:

  • Teach something new
  • Complete a specific task
  • Help the other person practice debugging
  • Connect or bond with a colleague
  • Practice pairing #meta



  Nothing Is "Easy"

After all, if it were easy for both of you, y'all wouldn’t be pairing. 

Calling things "easy" can been a tough habit to break. It's natural to lose track of what you already know, and this only compounds as you get further and further in your tech career. 

Alternatives to describing something as "easy"

  • "I'm confident this is within your abilities, especially if we work on it together."
  • "It seems complicated, but once you know XYZ, it's actually straightforward."
  • "It's possible you're overthinking this, which is easy to do. Try approaching it this way, and I think it'll be clearer."

Avoid statements like, "You don't know XYZ??"

Related, try to not act surprised when the other person doesn't know something that feels universal or basic to you (this goes for both junior and senior pair members!). There's a ton that juniors don't know, by definition - but conversely, even those in tech for 15 years don't know everything, and have likely forgotten a fair number of things they used to know. 

Instead, I try to reframe the moment as opportunity: "I'm actually excited you haven't encountered this yet, because that means I get to show it to you!"


Better to over-explain than under-explain

When I start a pairing session - especially if it's someone I don't pair with often, or if it's a pairing topic we haven't worked on before - I like to start by saying something like, "I'm going to intentionally tell you what feels like too much detail as we get started, just because I'm not sure what you do and don't know. Feel free to poke me if I'm over-explaining!"



  Regular Check-ins

"What questions do you have?"

I can't remember which speaker shared this tip at which conference, unfortunately, but it's something I've taken to heart. 

Instead of asking, "Do you have any questions?", she recommends phrasing it as, "What are your questions so far?"

It's a small change, but makes a big difference in terms of providing space for the other pair to be vulnerable by assuming  they'll have questions, instead of putting the onus on them to admit they don't understand something.

Betsy Haibel talked about this need for creating a pairing safe space at RailsConf this year:


Summarize frequently (and with non-technical terms)

Have them explain periodically what you’ve done so far, and summarize again at the end. Related, have them use "plain English" for those summaries, so that they can't hide signs of confusion behind technical jargon.

Take breaks

A study from Stanford showed that taking a short walk - even within your building - makes you more creative for a short period immediately afterwards. Who doesn't want that?



  Coach, Don't Tell

Pairing, at its core, is about learning, and it's difficult to learn if someone just tells you the answer every time. Oftentimes, either before pairing or as the first steps of a pairing session, we have the junior pair work through our "How to Ask For Help" guide.

Some other things to consider here: 

  • Give the other person time to think before jumping in with the solution. Ask questions that lead them to the right answer, instead of just giving it to them.
  • Be careful about pointing out typos / syntax errors; learning to catch such errors oneself will build crucial debugging skills. That being said, this is highly contextual: if a primary purpose for pairing is to finish something on deadline, then by all means, don't let typos trip your pair up.



  Build Bridges

As Brett loves to say, "Nothing is magic." 

What he means is that everything we do in tech is based on code, and if we really wanted to, we could dig into any framework, gem or module and see exactly what's going on behind the scenes. 

Everything can be learned.

Being deliberate when talking about code connections helps drive this home, and reinforces for juniors that there's a method to the seeming madness of programming. Explain why you're navigating to a certain file; what you expect to find; why you expect to find that; and, if possible, bring it back around to something you've already done while pairing or that you know your partner has experience with.

The better the junior pair understands those connections, they more likely they'll be able to make those connections themselves in the future. 



  Misc. Tips

Have them take notes!

  • Provides reference for next time
  • Helps them pick back up if you're interrupted or run out of time before finishing
  • The simple act of writing things down can also help solidify them in the brain

Don't get fancy

If you have a highly customized development environment (or use Vim #kiddingnotkidding), consider switching to something more universal for pairing sessions. Otherwise, the other person literally might not be able to follow along.


Excitement is infectious

Try to be excited about pairing! The junior will almost certainly find the situation much more frustrating and challenging than you, and having a positive attitude will go a long way.

pairing tech
Author details

Hilary Stohs-Krause

Co-Owner and Senior Software Developer
@hilarysk