Pair programming is invaluable when helping someone learn and grow as a developer, but too often we don’t take the time to think about how we go about it. The little decisions we make along the way can make a big difference to the effectiveness of our mentorship. In my recent talk at RailsConf 2024 in Detroit, I explored my experience mentoring and being mentored and took a closer look at how the decisions we made affected the outcome.
Many mentor/mentee pairs start off without thinking too hard about exactly how to pair together. It’s common to take most convenient path without considering whether it’s the best one. Instead, start by making a plan. This puts you on a path to making intentional decisions throughout your time with your pairing partner. I like to consider a few things first when making these choices.
Make it explicit what the mentee is looking to learn. The mentee often has some ideas here, but sometimes they need a bit of help to figure out exactly what they should be focusing on.
You can start by considering your own expertise, but don’t feel constrained by it. Collaborative learning is the heart of pair programming as mentorship. It can provide your mentee with insights into how you solve problems if you don’t have all the answers to start with.
At Super Good, we’re all working remotely and many of us don’t work on the same project. When a mentee needs help with something, the mentor might not have the project set up and might not have context on the full scope of their work. This usually led to having the mentee drive, which has pros and cons. Consider the constraints and limitations in your company when deciding how to pair. I explore these further through case studies in my talk.
Take a moment to think about the boundaries of what you should be learning. With a very junior developer we might want to avoid discussions about design patterns, as they’re just learning some basic syntax and language features. On the other hand, with a more experienced mentee, we can focus less on the basics of writing code and more on exploring more complicated patterns and ideas.
There are a lot of possibilities when it comes to how you can set up a pairing session.
The driver and navigator roles in pairing are very different. In our process at Super Good, we usually let whoever had the project set up on their computer drive. I found that letting mentees navigate instead left them free to focus on solving the problem at hand. It also them to how senior developers write code, a chance they might never get if they’re always driving.
The length and cadence of sessions affects how we pair together. 30-minute sessions multiple times a week can help keep someone moving when they’re having trouble with implementing something smaller. Longer, less frequent sessions are a good place to plan and design larger pieces of work. Consider which is better for you and your mentee’s learning goals and personalities.
There are lots more variables you can tweak to improve your pairing experience. You can pair in-person or remote. If you’re remote, then you can choose different tools. If you’re in-person, then you can choose your setting. Keep trying different options to see what works best for you and your mentee.
Once your plan is in place, regular pairing sessions are only the beginning. Some ideas that seem good at the outset might not work out how you expect. That’s why it’s important to take a little bit of time every so often to refine your pairing strategy.
Look back at the learning goals you wrote down in the beginning and ask how you’ve been doing. Maybe you’ve accomplished your goals and need to pick new ones. Maybe they’re no longer relevant or maybe you need to refocus because things have gone off-track or haven’t made as much progress as we hoped. Regardless of the progress so far, this is the most important piece of learning to pair with your mentee. Take stock of how you’re pairing together, how that has affected each of you, and then make changes so that each of you is getting as much as you can out of your time together.