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.