One-on-one mentorship is my way of implementing our third core principle at Zeal, Bridging The Gap. Remote pair programming is a satisfying and effective tool for raising up the skill levels of those around you.

Pairing with Junior Devs

Junior developers need time and mentorship with their senior and mid-level colleagues to develop. This can be passive in the form of pull request reviews, but is so much more effective in a one-on-one live format. My junior dev colleague and I stick to this format:

• We do remote pair programming for 1 hour twice a day at the same times every day. This allows both of us to better plan out our day and avoid interruptions.
• We collect problems that we need each others’ help with and start with those. This focuses our sessions directly on the gaps in our knowledge and getting unstuck.
• Junior devs need more time than senior devs to read and understand code and to work through the more mundane parts of implementation. Not pairing for the whole day gives junior devs solo time to accomplish these things without the pressure of another engineer looking over their shoulders.
• My junior colleague occasionally reaches out to me before our scheduled time to get unstuck. This is the right thing to do!

‍

Pairing With Strangers

At a recent pre-quarantine conference, I was talking about my experiences with remote pairing with a small group of people. One person said “I’ve never done that before.”, so I handed them my business card. That person and I have paired on side projects on 3 separate occasions and have learned quite a bit from one another already!‍

You don’t need permission to do a remote pair programming session with a person you don’t know well. Be sure to use care when it comes to your private information and what you share on your screen.

The next time you see someone struggling with an issue at a conference, meetup or community Slack/Discord, give this a try!

Be A Mentor To A Friend

I’ve recently had the opportunity to pair with a friend from high school who is one of two junior devs at a website design agency. Not all junior and early-career developers work in companies filled with potential mentors. As friend mentors, we can show isolated developers new techniques and tooling to adopt, and help get them unstuck on problems they haven’t experienced yet.

Ways That I Have Done This Wrong

Please feel free to not repeat this list of mistakes I have made

• Pairing for too long without breaks or solo time. Particularly the case with remote pairing, be sure to take 5-15 minute breaks every hour or so to give your mind a break.
• Pairing “Whenever”. An ambiguous offer to ‘pair whenever’ sounds generous, but I have found that these sessions are more likely to happen when they are scheduled. “When will so-and-so reach out to me?” is also a distraction that is unnecessary. Sticking to an hour also prevents you from overcommitting your time.
• Interrupting Too Much. A great tip I picked up from Tuple’s Guide to Pair Programming - don’t interrupt your pair right away for tiny mistakes. An interruption can derail your partner’s train of thought and they will likely catch their own mistake eventually.
• Forcing Your Solution. When helping another dev, present your ideas as alternatives. Be persuasive about why you recommend that your pair change their approach.
• Rushing Troubleshooting. One of the most valuable skills a junior dev is developing the ability to understand why things aren’t working the way they expect, and this takes time. If you see the problem right away, nudge your partner by talking about what you noticed that helped you see the problem, rather than jumping to the solution right away.
  

A note about imposter syndrome: If you know anything about anything, there is definitely a person that knows less than you about something, and that person can absolutely benefit from your help regardless of the ‘Junior’ or ‘Senior’ next to your title. All of the progress I have made as a developer has come from learning directly from all of colleagues and teams that I have worked with as a consultant.