Mentoring and Time

Wednesday, July 9, 2014
Tags: community, GSoC

No, this is not about being late places, it’s about respecting people’s time. I won’t go deep into why this is important as, Michael Haggerty wrote an awesome article on this. His thoughts boiled down to a single line of advice:


I think this applies to any type of mentoring, and not only open source work, but any formal or informal mentoring! This advice isn’t meant just for GSoC students, for interns or new employees, but also things I’d like to remind myself to do when someone is helping me.

To make this sound positive, I’d reword the above advice as:

Respect other people’s time!

Someone is willing to help you, so assume some good faith, but help them help you! Some actions to focus on:

  • Ask focused questions! If you do not understand an answer, do not re-ask the same question, but ask followup question. Show you’ve researched the original answer and attempted to understand it. Write sample code, play with it, etc. If you think the answer given doesn’t apply to your question, reword your question: your mentor probably did not understand.
  • Be cognizant of timezones: if you’d like a question answered (in realtime), ask it when the person is awake! (And this includes realizing if they have just woken up or are going to bed.)
  • Your mentor may not have the context you do: they might be helping many people at once, or even working on something totally different than you! Try not to get frustrated if you have to explain your context to them multiple times or have to clarify your question. You are living and breathing the code you’re working in; they are not.
  • Don’t be afraid to share code. It’s much easier to ask a question when there’s a specific example in front of you. Be specific and don’t talk theoretically.
  • Don’t be upset if you’re asked to change code (e.g. receive an r-)! Part of helping you to grow is telling you what you’re doing wrong.
  • Working remotely is hard. It requires effort to build a level of trust between people. Don’t just assume it will come in time, but work at it and try to get to know and understand your mentor.
  • Quickly respond to both feedback and questions. Your mentor is taking their precious time to help you. If they ask you a question or ask something of you, do it ASAP. If you can’t answer their question immediately, at least let them know you received it and will soon look at it.
  • If there are multiple people helping you, assume that they communicate (without your knowledge). Don’t…
    • …try to get each of them to do separate parts of a project for you.
    • …ask the same question to multiple people hoping for different answers.

The above is a lot to consider. I know that I have a tendency to do some of the above. Using your mentors time efficiently will not only make your mentor happy, but it will probably cause them to want to give you more of their time.

Mentoring is also hard and a skill to practice. Although I’ve talked a lot about what a mentee needs to do, it is also important that a mentor makes h(im|er)self available and open. A few thoughts on interacting as a mentor:

  • Be cognizant of culture and language (as in, the level at which a mentor and mentee share a common language). In particular, colloquialisms should be avoided whenever possible. At least until a level of trust is reached.
  • Be tactful when giving feedback. Thank people for submitting a patch, give good, actionable feedback quickly. Concentrate more on overall code design and algorithms than nits. (Maybe even point out nits, but fix them yourself for an initial patch.)