10 Tips for Mentor/Mentee Relations

Written by on .

I was digging around in Evernote today and found an old note that I wrote back when I was supervising undergraduate students performing research. One of the things I do now is work with aspiring game developers through the GameMentorOnline program, and I was surprised by how much of this applies to this kind of relationship as well. I figured it might be of interest to someone who was looking to start mentoring but wanted to see how others structure their approach and set boundaries. I think the big thing for me is making it clear that my role is not to be a teacher or a tutor and ensure that my expectations are clear and upfront – so that we are both on the same page, but also early enough that the mentee can find another mentor if they need.

  • I always read my email. I don’t always reply immediately, particularly if I need to look something up or test something first (e.g. debugging). Then I forget about it. If you haven’t heard from me within a day or two of sending me a question, remind me about it and nag at me til I do what you need.
  • I typically expect you to meet with me for up to an hour per week, but there are going to be weeks where you haven’t made enough progress to warrant a meeting. It’s totally acceptable – preferable really – to drop me an email and say that rather than come in and waste both our time. The sooner you can let me know, the happier I’ll be, and if you blow it off 10 minutes before, I’ll be quite unhappy. An hour or two should be considered minimal notice, the evening before would be better.
  • I’m not good at beating around the bush. I could ramble for a paragraph or two about how good what you’ve done so far is and pander to you a bit, or I could cut right to the chase, point out what you need to fix, and spare us both the waffle. Don’t take it personally, but also consider that the things I’m not talking about are implicitly OK.
  • Your project is a major piece of work, it should take a lot of work from the start to the end. You can’t throw something together at the end and expect a good grade. Equally, my job is not to get you a good grade. I will guide you, be a sounding board, tell you when I think you are going wrong, but ultimately the responsibility for the work lies with you.
  • With that said, I want to see you succeed, so pay attention for “suggestions” during meetings and advice that isn’t necessarily as optional as it might sound – if I suggest that approach X might be a good place to look for an answer, I’m not saying “check Y and Z first”, I’m saying “Do X and let me know how it works” :)
  • This is less a tip about working with me, and more in general : Always, always assume that the problem is with your work. If you find yourself complaining that Eclipse doesn’t work right, Java isn’t behaving the way it should do or the codebase you’re building on is broken, make sure that you’ve checked your side of it thoroughly. Nothing is going to get people irritated more than crying wolf. With that said, if you can verify a problem, have the confidence to flag it and make sure it gets sorted. No code is perfect (god knows a lot of the codebases you guys are going to be working with aren’t), but it is very frustrating to be told there’s a problem with the code only to find that it’s blatantly a basic mistake with the student’s code.
  • I was a total screwup of an undergraduate. I’ve used every excuse, I’ve heard more since then. You’ll get more respect by acknowledging your mistakes and dealing with them than by trying to pass them off. We all get RSI, headaches, sickness. The dog may actually eat your homework. The true test is whether you can get the work done anyhow.
  • Speaking of RSI, expect to get at least a mild version toward the end of the project. Plan accordingly. Allow more time than you think you will need to write up.
  • We’ll get you set up with SVN. This means you can keep a single version of your files, rollback when you make mistakes and all the other good things that version control allows. It also allows me to look over your shoulder without having to chase you for source on a regular basis, so try to keep it up to date reasonably regularly – at least once a week – and please use meaningful commit messages so I’m not chasing through looking for changes that aren’t important, or wondering why something doesn’t work because you didn’t indicate in the commit that it was incomplete. Commenting your code is always a good idea and can be a big help, but making it readable and accessible (for instance, not using obscure names or giving method names that don’t reflect the actual purpose of the method) is more important. (This one was very specific to the research supervision I was doing at the time – as I’ve moved to mentoring, I now set the expectation that I won’t be looking at my mentee’s code)
  • Finally, I’m not paid to supervise you. I do it because I love the work, and maybe occasionally something publishable comes out of it, which is good for all our CVs. As a result, you’re going to get from me what you put in – if you work hard, I’ll work as hard as I can to help you. Equally, if you don’t work hard, don’t expect me to go very far out of my way for you.

Hopefully this will be of use to someone, but if not, I now have an easy reference to it to share with my future mentees! Let me know in the comments if you have a different style, or what your tips would look like.

  • Ernest W. Adams

    Useful stuff, although it would be handy to explain what SVN is and where you get it.

    You don’t know how many hours I’ve spent debugging stuff that turned out to be somebody else’s fault. Infuriating. And my wife found two bugs, at different companies, in — so help me — the math libraries. You would think that we would have basic trig functions down, wouldn’t you?

    The message I take from this is, yes, the chances are most likely that it IS your fault… but don’t beat yourself up about it or let it stress you, because there’s always a possibility that it ISN’T your fault.

    • http://lukedicken.com/ Luke Dicken

      SVN sounds like an easy post idea for a follow-up at some point thanks Ernest.

      I agree that the libraries are rarely perfect, but the number of times undergraduates blame the library, or the language or the IDE is crazy. Covering lab sessions as a TA, the cocky ones would almost every week have some bitch session about what was wrong with X now – and generally it was that they’d not read the documentation thoroughly.

      For these projects I was supervising, because I was the one telling them what libraries to use, and they were generally often using libraries I’d built or had a hand in I was initially way too willing to believe problems which is the origin of the point. Clearing an afternoon to solve an issue that you can’t replicate and it turns out it’s an issue their end that they’ve not properly debugged got old very fast :)

      Looking forward to catching up next week btw!

  • Pingback: Luke Dicken – More Thoughts for Mentors()

  • Pingback: Different Ways To Mentor and Mentee Expectations | Sheri Rubin's Online Home()

  • sherirubin

    Thanks Luke for writing this. I have some similar and differing styles and wrote up a short blog post of my own so I also have it for easy reference here: http://sherirubin.com/2013/10/different-ways-to-mentor-and-mentee-expectations/

    Thanks for spending some of your time to mentor others – I know it makes a difference!