Pair programming is part of Tandem’s DNA. It enables us to craft quality software, and when done right, it fosters collaboration, empathy, and self-reflection. Since joining Tandem, I’ve had the opportunity to pair with developers across all levels and discovered that there’s not a one-size-fits-all approach. I strive to adapt my pairing style to my partner, which I’ve come to recognize as individualized pairing.
This post is not about methods of pair programming: you can find a ton of that information elsewhere. Rather, it’s about how to take cues from your partner and embrace each other’s strengths. I’ve pulled out a few themes for pairing across different skill levels to incorporate into your next session.
Table Stakes for Any Pairing Session
First and foremost, here are some things to actively consider to ensure everyone has a welcoming, safe, and productive pairing experience.
- Be aware of power dynamics. Pair programming does not occur in a vacuum. Multiple power dynamics can exist along lines of race, gender, age, experience, and authority. If you are on the upward side of the power dynamic, it is critical to be aware of that inbalance and find ways to actively neutralize it. Birgitta Böckeler and Nina Siessegger wrote extensively on pair programming, and I especially liked their thoughts on power dynamics.
- Don’t make assumptions. Ask your partner about their experience with a new language or familiarity with the code. This table-setting helps prevent any misunderstandings down the line.
- Share wins and ownership. Recognize your pair and share ownership of the code, no matter who did the typing or who is more experienced. I like to do this by calling out their contributions in my pull request descriptions or standup updates.
Pairing With Someone With Less Experience
When I was first stepping into a mentorship role, I worried about going too fast or not providing enough guidance to our apprentice engineers. But perfect is the enemy of good, and you don’t need to have all the answers for you both to get value from the experience.
- Give time and space to think. If working on an appropriately leveled piece of work, your pair probably just needs a few minutes to reach the right conclusion on their own. Resist the urge to fix their mistakes immediately. Go at their pace and ask guided questions to help them arrive at the solution, instead.
- Look things up together. It’s 100% okay not to know the answer to every question, like how a certain library method works or what a piece of syntax actually means. Be honest about it, and then do the research together. Early career engineers can learn a lot about traversing documentation or vetting Stack Overflow answers through this process.
- Know that your way is not the “only” way. Mentorship can be similar to consulting in that you provide suggestions and the rationale behind those suggestions, as opposed to claiming your way is the right way. Point out areas that are up to personal preference to let your pair develop their own coding style.
Check out this blog post for more tips on pairing with early career developers as well.
Pairing With Someone With Similar Experience
Pairing with someone at your level is a wonderful opportunity to stretch that muscle in a different way, especially when tackling bodies of work with ambiguity. Read more about an awesome pairing session I had with my colleague Shamyle Ghazali in a previous blog post here.
- Acknowledge their areas of expertise. One of you might be a frontend expert, while the other finds more comfort in the backend. Appreciate what your partner brings to the table and how that makes you stronger, together. This can ring true across other levels as well.
- Bounce ideas off of each other. I love working with someone at my level because it gives us room to be creative with our technical toolkits. While a more experienced engineer might be quick to see the optimal solution, you learn so much by trying different approaches to a problem as a team.
- Take turns. This dynamic is also special in its flexibility. Take turns switching off between driver/navigator and explaining code to each other. This activity is a great way to make ownership of the code feel shared.
Pairing With Someone With More Experience
Knowledge-sharing is one of the most obvious (if not trite) benefits of pair programming. While the senior developer is usually responsible for providing mentorship, there can absolutely be more nuance in this experience. You can create value in a pairing session beyond simply absorbing technical information like a sponge.
- Ask for what you need. Communicate with your pair when you’re mentally processing code, taking notes, or need them to repeat something. I’ve certainly sat in pairing sessions during which every single word went over my head. That’s not a good use of your time or theirs. You should feel empowered to ask to slow down, decrease the scope of your working session, or focus on something specific.
- Dig into decision-making processes. If your pair makes a technical decision you don’t understand, prod them on their reasoning. This practice helps the senior developer understand a concept more deeply, and also provides invaluable information for you to evaluate similar technical situations in the future.
- Find opportunities to teach or lead too. Have confidence in your own knowledge and ability. You may have more context about a certain feature, past decision, or language. A good senior developer will be happy to consider your ideas and support you if you make a misstep.
Working with someone closely is hard. You’ll have some amazing pairing experiences and some not-so-good ones, depending on the day. (On that note, be transparent about how you’re feeling to avoid burnout–I give my teammate a heads up when I’m not in the best mood and need more breaks than usual). As always, give and ask for feedback generously. If your pair did something you loved, let them know! And don’t be afraid to ask what you can do better for next time. Pairing is a skill to be practiced, and there’s always room to grow.