There’s Method to the Mentoring: Advice from a Teacher Turned Developer

Research psychologist Anders Ericsson has spent decades studying the science of expertise, attempting to answer the age-old question of nature versus nurture when it comes to attaining mastery in a field. His findings indicate that it is not only the quantity of practice that is required to become an expert in something (10,000 hours, if you were wondering), but the quality, which he’s termed “deliberate practice." Deliberate practice involves well-defined, specific goals that are targeted to improve some aspect of performance. He shares in a recent Freakonomics podcast:

“Deliberate practice relies on this fact that if you make errors, you’re going to find ways to eliminate those errors. So if you’re not actually stretching yourself outside of what you already can do, you’re probably not engaging in deliberate practice.”

There are a couple of valuable takeaways here. The first is that errors are indispensable to learning, something I can attest to from my years as an English language teacher. This is perhaps just as true in software development, where one of the first things a programmer learns is how to read and interpret the many types of errors that a buggy program will throw. Both mentor and learner are best served by making space for errors, hiccups, and failures in the learning and teaching process, something that will inevitably happen for both parties.

The second takeaway is the importance of being “stretched” outside of the comfort zone of what one already can do. If you aren’t being challenged to try new things, your horizon will stay right where it is. It’s important to note that being stretched too far can be just as pernicious as not being stretched at all - that is to say, it is important for a mentor to develop the ability to assess the level of difficulty of the challenges being proposed to the learner. Being thrown into the deep end before learning how to swim can lead to a strong adversity to water and in some cases, the desire to never code again.  

Whether you’re interested in becoming a mentor, have been mentoring for years, or are curious about teaching practices in the context of software development, the five pieces of advice below should give you a general idea of what to aim for and expect from the mentor-mentee relationship.

1. Admit when you don’t know something.  

The main question that should continue to surface for a mentor is how to provide enough contextual information without solving a problem for their mentee. In other words, what’s the right balance of challenging versus saving? Being explicit about not knowing something is a great way to avoid unnecessary confusion. By concealing what you don’t know, your mentee is left to assume that you do in fact know the answer and in a desire to succeed, is more likely to conceal in turn what they also do not know. Acknowledge when you don’t know something and immediately provide an explanation of how you would go about solving the problem. Apart from highlighting the role of humility in the error-prone learning process, it can be an excellent opportunity to demonstrate your debugging strategies and encourage autonomy. 

2. Ask and expect a lot of questions.

As a mentor, your objective is to understand why your mentee doesn’t understand something. It’s just like debugging: you need to first recreate the error to understand why and how it’s happening, and from there you can act accordingly. In this case, the “bug” is figuring out the gaps in your mentee’s understanding, and to do that, you need to ask questions. The best mentors are the ones that consistently do this, and it makes all the difference in the world.

If you feel like you aren’t getting enough questions from your mentee, ask open-ended follow-up questions (questions that can’t be answered with a simple yes/no). For example, “Can you walk me through the life cycle of this object based on your current understanding?” is a better question than, “This all makes sense, right?” On the other hand, if your mentee is asking questions at inopportune moments - for example, when you’re explaining something - let them know that you want to answer their questions but ask them to hold off until you’re done. For a great primer on ways to think about formulating and asking questions, check out this article by The Teaching Center at Washington University.

3. Give feedback early and often.

Growth depends on a feedback loop, which is necessary for understanding what we should be doing differently to improve. Feedback can come in many forms - positive, constructive, negative, verbal, textual, tacit, etc. It can be given during a weekly chat over coffee, in an email, and/or in the day-to-day learning process. Whatever the form, it must be given regularly. 

For feedback to be useful, it should be specific, reference clear examples, and provide a context for setting expectations. For example, if you think your mentee doesn’t spend enough time researching answers before coming to you, you could say, “Try spending at least 15 minutes looking into a solution the next time you’re stuck.” If your mentee tends to be vague or disorganized with descriptions of their blockers, you could advise them to take a moment to write down their current understanding of the issue, what they expect to be happening, and formulate their questions before coming to you. Check out Halogen Software’s article on giving effective feedback for more pointers, as well as this article on being radically candid, one of Truss’ core team values.

4. Pair program.

Pair programming is an excellent way to expedite the learning process. It involves externalizing thought processes, modeling workflow practices and debugging strategies, and requires real, live communication about what you think the code is actually doing. On the other hand, it can be slower than working solo, according to this commonly cited study, and feel more unproductive in the short term to some engineers. In spite of its perceived drawbacks, benefits of pairing include improvements in design quality, reduction in bugs, enhanced technical skills, and increased efficacy in team communications.

If, for whatever reason, you don’t find pairing to be particularly useful for the task at hand, avoid taking over your mentee’s computer without asking mid-pairing. In fact, it’s probably a good idea to refrain from commandeering their computer at all. The consistent urge to do so can be seen as a sign that you have the wonderful opportunity to improve your communication skills. I encourage you to take it.

5. Use your words.

When you find yourself explaining something multi-faceted or particularly complex, it can be easy to fall into the anti-pattern of not externalizing your thought processes. From a mentee’s perspective, this can look like you staring at your screen in eery silence. In these situations, it’s a good idea to either take a moment to yourself to collect your thoughts or make a conscious effort to share aloud what you’re doing. The way in which you explain what you’re doing can make a huge difference as well. For example, “I’m extracting lines 79-85 to an external method” is not as informative as, “This code repeats itself in a few places, so I’m going to refactor it to be easier to read."

Additionally, it’s probably a good idea to filter out the following words from your vocabulary when talking with your mentee: obviously, just, easy, and super easy. It will take a little practice, but being conscientious about not using words that inherently impose expectations and pass judgement on someone to whom what you’re talking about seems to be the exact opposite of ‘obvious’ is not a bad idea.

Conclusion

Needless to say, the success of a sustainable mentor-mentee relationship is directly dependent upon trust and confidence: both parties must be able to trust that the other has their best interests at heart and have confidence that the process will yield results in the form of measurable growth. Through admitting your gaps of knowledge, providing regular constructive feedback, pair programming, and being conscientious of the language you use, you will undoubtedly become an invaluable resource for those learning from you as well as those working with you.

Just as your mentee believes in and respects your abilities, you too must respect their ability to grow and believe in the skills that have gotten them to where they are now.