On Mentorship
This is the second of three articles about mentorship, and is for mentors. The first one can be found here
“Always two there are, no more, no less. A master and an apprentice.”
The first part of this series was for people in management roles. It encouraged managers to pair one mentor with one junior, choose a mentor based on certain personality traits, and to adjust the mentor’s dev workload so they can wear both hats without imploding.
But as we all know, sometimes we start out with the best intentions only to fall into a mire of confusion, apathy, and other evils. As the intermediary between student and manager, a lot of the issues can fall on your head unless you set clear boundaries with everyone involved and bring clarity where there was only an ill-defined fog of misunderstandings and Bad Ideas. This article is meant to help you do that.
Let’s start by laying out some of the biggest challenges I’ve observed in mentorship. They are:
- Not having enough time to help your junior while also completing your tasks
- Feeling frustrated and unappreciated by your boss and/or your junior
- Feeling under-qualified to teach a junior who’s lower than you expected
On paper it doesn’t sound so bad, but because a lot of new companies lack an understanding of these problems, many mentors are stuck stewing in vague and oppressive varieties of doom without much of a support system. If you’re in a small company or a startup, it might be up to you to educate your company about mentorship while also educating a new developer. That’s a battle you’ll have to fight according to the circumstances you’re dealing with, but the most important thing is to make sure that everyone involved agrees on how much time you have for dev and how much time your have for mentorship. It’s important that you train them to respect that time, or you will go crazy.
“Always pass on what you have learned.”
Doing a good job of it involves a combination of structure and sensitivity. As far as structure goes, you’re probably not going to get a curriculum or learning resources or a budget. You probably won’t have a well-defined way to measure your padawan’s progress. Your student will suffer from these things and the worst thing you can do is fail to understand the resulting confusion. You have a hard job.
Let’s address these issues one at a time. When it comes to a curriculum, operate under the assumption that they learned some subset of the knowledge they need in some kind of formal setting, and operate as if it’s not your problem. When it comes to learning resources, the problems they need to solve combined with The Wise and All-powerful Oracle (the internet), will largely suffice, which takes care of budget too. The thing that a lot of mentors don’t think about is that the biggest thing a student needs is to understand how to use those learning resources. Without guidance, they might read the documentation 200 times over without being able to put it to use. They have a poverty of experience to draw on, so without seeing lots of examples, translating documentation to successful implementation can fall somewhere on the spectrum between hard to impossible.
Pair programming for a certain amount of time per day can be really useful. Once they’ve worked through some common problems with you, they’ll be in a better position to translate the errors and nulls into something Googleable. Pairing for an hour or two a day for the first month will ultimately save you a lot of disruption and despair. At least that way you can set limits on how much time you spend on a problem, and can put some quality time into understanding what your student needs to learn while checking your own assumptions about the problem.
“If you end your training now — if you choose the quick and easy path as Vader did — you will become an agent of evil.”
Measuring a student’s progress requires some attentiveness on your part. If the kinds of things they’re working on are repetitive, at least you have something constant you can check their knowledge against. In reality, most new tasks will put your student well outside of what they know. The best thing to do is emphasize proficiency with debugging tools, understanding documentation, and framework fundamentals. You can probably observe improvement in these things and keep nudging it forward as you work through implementation details.
As you work, remember that the most valuable thing between you and your student is their lack of understanding. That’s where you should direct your attention, because it’s the barrier you’re trying to reach each other through. It’s also the most uncomfortable aspect of knowledge transfer because it requires both parties to tolerate high levels of confusion and frustration.
There are a few common anti-patterns that emerge from this hell. On the mentor’s part, they are:
Repeat an explanation that didn’t work
Get angry at the student for their stupidity
Give up.
Let’s look at each of these in turn.
Repeat an explanation that didn’t work.
This shows a lack of awareness on the mentor’s part as to what the student does and doesn’t understand. That’s why it’s so important to put that annoying time in when a student first explains a problem to you. They will sometimes say things that are wrong or stupid, but you must resist the urge to slap their hands away and talk to their console. You have to teach them to ask their console their stupid questions so that you hear fewer of them. After they’ve had a little time to spill the beans, ask them the questions that they should be asking about the problem and show them how to use their tools to get the answers. This is a very informative process in itself. Once you’ve gone through that, take out a notepad and explain some of the higher level concepts they’re missing. Help them understand how the information you got from the console fits into the problem. This approach ensures that you are empowering your student while assessing where they’re at.
Get angry at your student for their stupidity.
“You think Yoda stops teaching, just because his student does not want to hear? A teacher Yoda is. Yoda teaches like drunkards drink, like killers kill.”
If your student knew as much as you did, they’d be making the same amount of money, doing the same tasks, and wouldn’t be your problem. In reality, they don’t know as much as you do, and they won’t understand the explanations that work on your peers. It’s your job to understand the problem well enough to explain it simply, with fewer nuances than there actually are. Being a good teacher means taking responsibility for their failures as learners. It’s essential to treat their misunderstanding as an objective lack of information where there should be data. Remember that they want to understand too. Blaming or getting angry about their misunderstanding makes you the stupid one.
Give up.
“I cannot teach him. The boy has no patience.”
Let’s say that having failed the battles with the previous two anti-patterns, you decide that you don’t want to do this, it’s too hard, your student is too stupid, and the only solution is to fire them. Maybe you have a whole bunch of rationalizations prepared so that nothing anyone says will bother you or seem to apply. At this point you have two choices. The first is to give up and let the same factors that led to your failure as a mentor spill over into other areas of your life. This might have been a chance to grow. Too bad.
“To be Jedi is to face the truth, and choose. Give off light, or darkness, Padawan. Be a candle, or the night.”
The second is to keep working to get better and keep going, just like you’re asking your padawan to do. This could be especially hard to stomach if a dysfunctional pattern has emerged between you and your student. Here is a very advanced debugging challenge: an opportunity to debug a human relationship, to really examine where things went wrong and how you might be able to fix it. You’re good at things like this — that’s how you got where you are.
Don’t forget how important this work is to your student, your employer, and our entire industry. It’s hard work with little public fanfare, but your knowledge gives you the power to empower everyone around you with your knowledge, and that’s pretty cool.
May the force be with you!
Please follow so you don’t miss part three, which is for students.
