Originally posted on Codementor

Codementor Matt Goldspink has 10+ years of development experience & background in delivering training courses. Having given 120+ sessions at Codementor, he still maintains a 5-star rating. In this article, Matt shares some tips on how to be a great mentor.

Signing up to be a CodeMentor is both exciting and very daunting at the same time! I have all sorts of doubts run through my mind with every session:

• What if I don’t know the answer?
• What if I take too long?
• What if the person I’m helping is some functional programming purist who is way smarter than me?

When I took my first engineering job out of college, part of my role was to work on a weekly Java mail group supporting the other 500 Java developers in the company (many with 10s of years of engineering experience). I felt way out of my depth! If those people can’t fix their problems then how the hell am I supposed to?

After a few weeks on the mailgroup, I soon began to realize that helping other developers has little to do with how much knowledge or experience you have with languages, frameworks and systems, but how well you can listen, understand and solve problems. Of course, knowing frameworks and languages helps, but that alone certainly doesn’t make one a great mentor. So I’d like to share with you a few of the most valuable lessons I’ve learnt over the last 10 years as a developer and code mentor.

Be kind and make a friend

This might sound a little bit over the top ( and I certainly don’t mean go crazy and organize a dinner party for the person you are mentoring), but always keep in mind that someone is reaching out to you for help. As thick-skinned as developers are, admitting we’re stuck takes guts and puts us in a vulnerable position. When someone reaches out to you, that person has to share their code and any holes in their knowledge with you. Who knows, perhaps the two of you may find that they’ve made a small typo and that will leave them feeling very embarrassed. So above all else, help them feel relaxed. There is absolutely no shame in getting help!

On a similar note… One of the best pieces of feedback I have ever received was to NEVER use the word “obviously”… Just because it’s obvious to you, it doesn’t mean it is obvious to everyone else!

Find out what the person REALLY wants to do

You’d be surprised – a lot of people will message you with a very specific code problem, but in reality their real headache is something utterly different. People frequently tend to get so invested into their thinking/coding process, that they get lost in their own solutions and they may be losing track of what they were initially trying to do.

Be realistic too- if going back to square one to solve the problem is going to involve a huge rewrite that’ll take days then don’t even mention it. That said, if it’s something that you know will only take a little time to rework and it will help get them back on track, by all means walk them through it and explain why it is a better solution. Just don’t drop their current solution completely. Sometimes people will just say “make it work now”, and they’ll be far more appreciative if you help them get things working, than if you blindly pushed some alternative “purist” solution. This one might be a tricky one to judge, so I usually say something along the lines of “well there is another solution which may mean rewriting what you’ve done, but it’s the recommended way. I can show it to you, or if you feel more comfortable with your solution we can focus on getting that working”.

Trust me- people will fall in love with you so much if you solve their real problem!

Be a good listener and think logically

99% of mentoring sessions are a surprise. When somebody approaches me, I’ve not seen their code; chances are I haven’t used the framework they’re using. I likely wouldn’t have written my code in the same way they did either. But you know what? None of that matters. What makes a great mentor is the ability to listen. As any psychology book will tell you, listening is an active task, so you need to be engaged and always ask questions such as “what does that line of code do?”, or “who calls this function?”.
You need to think through every line of code logically. Is that “if statement” really going to evaluate to true when the person you are helping says it will? Will that function always be called with the values they say? The person might think they know the answer, but sometimes you need to push them a little to “prove it” – crack open the debugger or set some log lines. Do whatever you can to gather all the evidence you need to make sure all your assumptions are correct.

Google is your (best) friend

Confession time! I can happily say I’m awesome with Google! When I worked on that Java support mail group I mentioned earlier, I would throw stack traces and all sorts of things into Google to see what I could find to help me out. 90% of the time the person who sent the email hadn’t even tried Google yet!!! I soon learned to spot the key phrases that would help me find the best Stack Overflow posts to help fellow developers out. 

So:

• Google – try all sorts of queries – if there’s an error, the first thing to do is to throw the stack trace into google!
• Read any API docs very carefully- many problems are caused by incorrect assumptions about what a function does. 
• Check for bug reports/issue trackers for frameworks in use – Just last week I helped a person who’d spent 2 days debugging a crazy problem with Promises in JavaScript. I checked the issue tracker on the framework they were using, and there it was- at the very top of the list; The exact bug they were describing with a pull-request for a workaround!

Wrapping up

Becoming a codementor is just the beginning of a great journey, full of extraordinary people and unthinkable code! So sign up, stay positive, be pro-active and enjoy every minute of it! Sharing your passion for code with others while helping them solve their problems at the same time comes second to nothing. And you never know what you might learn from your mentee….

See Also:
How to be an Effective Code Mentor – Part 2: Long-term Mentorships