On Effective Pair Programming
Helping junior engineers become more independent
Pair programming is an incredibly effective way to help junior engineers grow. Through pair programming, junior engineers can become more independent, develop new skills, and learn how to recognize similar problems long after the pairing session is done.
However, when done incorrectly (or impatiently), pair programming can become a crutch which stifles the growth and creativity of junior engineers.
It takes a lot of practice to get the most out of pair programming. In fact, I fell into all of these traps for about six months before realizing that I wasn’t helping. I wrote these guidelines in an effort to help you skip to the front of the line.
Disclaimer: There are many reasons to pair program. While the tips here are broadly applicable to most pair programming sessions, we are focused here on pairing with junior engineers where one of the key goals is learning.
1. Growth over speed
We all feel the pressure of deadlines — it’s only natural. But it’s important to remember that we pair program because we want engineers to grow.
Let’s be honest here: If speed were our priority, we wouldn’t pair at all. It would be faster for the most capable engineer to take the challenging work for themselves. Pairing is only likely to slow us down.
This is an important trade-off. We are temporarily slowing down because, in the long term, this focus on growth will lead to faster, more consistent output for the entire team.
Sometimes, this trade-off will not be worth it, and that’s okay.
If we’re considering cutting corners while pairing because we need a feature to ship, we should recognize that and reconsider whether we should be pairing on this work at all.
If speed is truly the priority right now (and sometimes it is!), we might consider breaking off a manageable piece of the work for our junior engineers to work on independently instead.
2. Questions over answers
The deepest learning happens organically, when a person can connect a framework or a datapoint to their own experience. If we give into the temptation to simply give junior engineers the answer right away, we are sabotaging their development as an engineer.
While it may feel like we’ve been helpful in the short term, this approach makes it unlikely that the junior engineer will understand why the solution worked. This makes it incredibly difficult for them to apply what they’ve learned in new situations.
Instead, our goal should be to guide them to their own conclusions with open-ended questions. While this approach may take more time (and a significant amount of practice on our part), it allows junior engineers to learn more organically by relying on their own understanding to solve the problem.
When done correctly, the junior engineer will come away with a deeper understanding of the problem and the solution, making it more likely that they can solve similar problems when they arise.
Not only that, but they will feel a greater sense of ownership over their work because they will have solved the problem on their own.
3. Guardrails over barriers
No two people will solve any complex problem in the exact same way.
A senior engineer’s role is to empower junior engineers to become more independent. For this reason, it’s important to avoid overriding a junior engineer’s approach to a problem without good reason.
Of course, we shouldn’t be reckless. We should be sure that the engineer understands the implications of their solution. But, if they understand the implications and the implications aren’t harmful, we should try our best to support them.
Before overriding their proposed solution, we should pause and ask ourselves the following questions:
“Does this actually solve the problem?” If yes, move on. Otherwise, block.
“Are there any edge-cases that are unaccounted for?” If no, move on. Otherwise, block.
“If this fails, does it fail gracefully?” If yes, move one. Otherwise, block.
“Does this break an important, established pattern in our code base?” If no, move on. Otherwise, discuss.
“Do I care about this enough to limit the freedom of this junior engineer?”
Given that we’ve even made it to the last question, it’s safe to say that this approach will not cause a catastrophic outage. In fact, if we’ve made it to the last question, then there aren’t even any easily-identifiable bugs that are likely to crop up.
In that case, it’s clear that our hesitation is due to personal preference rather than well-founded technical problems. As a rule of thumb, you should not answer yes to the last question more than 10% of the time.
4. Short sprints over marathons
Early on, it’s likely that we’ll be pair programming with a junior engineer for their entire ticket. This can be helpful for building confidence when acclimating the junior engineer to the team, or when it’s their first engineering role. However, as we progress, our goal should be to gradually reduce the length of our pairing sessions.
It’s hard to break the habit of pairing for an entire feature. It can be scary for a junior engineer to take on more of the work on their own. Not only that, but stepping away can also make us feel like we’re being less helpful.
However, it’s important to remember that our goal is to build independence. We can’t do that if we never give them the chance to work on their own.
As junior engineers progress, pair-programming should move away from marathon-style sessions that cover everything and toward short spurts that generally fulfill one of the following purposes:
“I’m lost” — If our junior engineer has no idea how to proceed, our goal is to pair just long enough for them to get a sense of direction.
“I’m stuck” — If our junior engineer is stuck on a known problem, our goal is simply to get them unstuck by asking probing questions so that they can continue to solve the problem independently.
“I have an idea” — Sometimes the junior engineer may just want our feedback on their approach. That’s great! Our goal is to provide feedback and then to let them explore.
By focusing our pairing sessions into short, targeted spurts, we make room for exploration while supporting when necessary. In fact, we can even use these three purposes as a way to gauge how much a junior engineer has grown.
As junior engineers become more independent, the average pairing session will start to shift from “I’m lost” to “I have an idea”. This transition takes time, but it’s one of the most fulfilling aspects of being an engineer.