By Ryan Palo September 5, 2018

Lessons Learned by Mentoring Programmers

Over the last two weeks, I’ve been mentoring programmers on Exercism.io on the Python language track. I saw the call for mentors on Twitter and wanted to help out.

Programmers submit their solutions to particular exercises, which come with tests, and it’s their job to make the tests pass. Then, the mentor—me, in this case—provides feedback on their solution, and they iterate until the mentor signs off.

It’s been a blast to teach others, but I’ve also learned a few things along the way that were surprising to me. I want to share those things to help others interested in mentoring programmers to have as great a mentor-mentee relationship as I’ve had.

1. You’re Ready to Be a Mentor Now

I really didn’t think I was ready to be a mentor. I mean, who am I to critique other people on their code? I’m just a self-taught hobbyist—I’ve never even coded professionally before. But after mentoring my first couple of exercises, I realized that if you have the right approach, there’s nothing to be afraid of.

There are really only two possible scenarios. Let’s have a look at them both:

  1. The person you are mentoring knows less or is less experienced than you in this particular area. Great! You can share your knowledge, help them level up, and feel like the wonderful person you are.
  2. The person you are mentoring knows more, has more experience, or comes up with a solution that you wouldn’t have thought of. In this case, as long as you are polite, considerate, and follow the rules below, everything will go fine. You’ll end up learning something new from them, you’ll tell them how well they did, and you’ll move on to the next one.

Either way, there is nothing to be afraid of. If the more experienced mentees are too intimidating, there are always the easier exercises where the mentees tend to be newbies.

2. Your Opinion Matters … a Lot

Your opinion matters to the student a lot more than either of you would consciously admit. Over the last couple of weeks, I went out of my way to find something I liked about each submission and comment on it.

“I love how you broke some of the logic out into a helper function to make your main function more clear.”

“Your solution is one of the most concise, but readable, that I’ve seen!”

I was amazed at how frequently I got responses like:

“Thank you so much for your feedback, it really means a lot.”

“I’m a newbie and not super confident in my code, so this makes me really happy.”

“Thanks! I really hope we get to interact again.”

I’m not showing these examples to show how good a mentor I am (#worldsgreatestteacher). Instead, these examples show just how big an impact feedback from a mentor can have even if I’m probably statistically likely to be younger and less experienced than the people I mentor and even if they know that I’m just a hobbyist on the other end of the comment box. Getting confirmation that someone else thinks you did a good job with something always means a ton.

In the same way, negative feedback has the power to crush somebody’s interest and motivation.

I learned that it doesn’t cost me anything to take a few minutes to find something positive about my mentee’s work. I learned to deliver feedback with love and to keep in mind that the end goal of motivating a student is to help them improve themselves. Either way, simply having that title of “mentor” gives me a surprising amount of influence on their learning, mood, and motivation.

3. Formatting Is the Easiest to Notice and the Least Important

When you look at a student’s solution, you’re going in with one or many possible ways to approach the problem in your head, and you’re expecting to see some form of one of them. All of the things that are different from the way you do them jump out at you. My first twitch is to want to just reach into their code and fix it right away before anything else.

It’s also the thing that will help the student the least and demoralize them the most because they see it as nitpicky, useless feedback that only makes the mentor feel better—and they’re right!

So, the solution I’ve come up with is to grind through the annoyance of bad formatting and try to make sure they understand the important concepts for that particular exercise. At the end of my feedback, once everything else is good, I might mention that they look into the language’s formatting standards and recommend a linter or an auto-formatter.

Every time I did it this way, they were excited to learn about those tools and standards and didn’t get frustrated.

4. Your Way Isn’t Always the Only Way

Another side effect of having a few possible solutions in your head is that other methods that might be correct may initially look wrong. Always consider whether the criticism you’re providing is the Right Way™ or just a personal preference, and when in doubt, err on the side of personal preference.

A mentor’s opinion has plenty of value, and most mentees will definitely appreciate the additional information, but it is important to make it clear to the mentee when your feedback is just personal preference unless you are sure that you are keeping them from Doing It Wrongalso TM.

5. You Are Not Wasting Their Time

I had to consciously force myself to not apologize for giving criticism or requesting changes to the code. I know it’s the introvert in me, but my gut instinct is to feel like they don’t really care about my feedback, and they just want me to sign off so they can move on to the next exercise. I feel this way, even though I’ve never had a single mentee tell me I was wasting their time! Two things have helped me get over this reaction.

First, I know that there are two modes on Exercism: mentored and independent. The people that I’m mentoring chose to be mentored. It’s what they want. If they don’t want to be mentored, I can happily tell them to take a hike switch over to Independent mode.

Second, I use the Right Way/personal preference split as a rough guide for when to ask for another iteration versus accepting their solution and simply suggesting another iteration. If my feedback stops them from Doing It Wrong, the feeling that I’m wasting their time lessens dramatically.

6. Use Questions to Collaborate

When providing feedback, it’s always better to assume the best and give the mentee a chance to defend their decision by phrasing my feedback as a question rather than just telling them they are wrong.

“I noticed that you used indices to loop through this list. Is there a reason why you didn’t use ‘enumerate’ instead?”

Asking the question immediately casts the conversation as a collaboration instead of a competition between the mentor and the mentee. It gives them a chance to explain their thought process and the pros and cons of the different options they thought of. It provides an insight into their problem-solving techniques, and it rules out solutions they’ve already tried that don’t have to be explained to them so that subsequent mentoring can be much more efficient.

Mentoring Is Love

You’ll notice that all of these rules are just specific applications of the concept that mentoring is love. Bishop Robert Barron has a definition for “love” that I really like: love is willing the good of the other, for their sake. As you’re mentoring, if you keep in mind that your overarching, primary goal is to help the other person understand, learn, be motivated, and grow, you can’t go wrong.

You won’t talk over their head or talk down to them because you know that doesn’t help them.

You’ll ask them questions about their thought process; you need to learn what they know before you can mentor them effectively.

You’ll cheer them on and celebrate their good decisions because you want to keep their fire to learn alive.

Even if their work isn’t perfect, you’ll know when to let them move on because there’s so much more learning to do.

And you’ll provide tools and solutions, not nitpick their flaws, because you want to help them avoid problems in the future.

To mentor is to love and to want the other person to grow, and if that is your goal, then you’re ready to be a mentor too.

About the author

    Ryan Palo

    Ryan is a mechanical engineer in the East SF Bay Area. He is a hobbyist programmer, with a focus on dynamic languages like Ruby and Python. His goal is to learn as much as possible and become a physics, math, and programming teacher. He writes about scripting, physics, simulation, data science, the web, and more on his blog at assertnotmagic.com. You can also see his articles and find links to his GitHub, LinkedIn, and Twitter accounts at dev.to/rpalo.