You are a senior software engineer and have just been designated the mentor of your team’s new hire. It’s your responsibility to bring this cadet up to speed on the large codebase that you helped architect, so that she can provide value on her own.
As a first task, you’ve assigned her to fix a recently reported bug, which will require only a small code change. You’ve given her an orientation of the codebase and all the resources she needs to succeed.
After working for some time, your apprentice becomes stuck. She has added logic to one of the sub-systems, but is not observing the expected results when running tests. How do you respond to her request for help? There are three common approaches:
- Point out the region in the codebase where she needs to put the logic in order to fix the problem.
- Take a step back and explain the purpose and behavior of the different regions of the codebase, so she’ll be less likely to make a mistake like this in the future.
- Tell her to RTFM (read the… manual).
Unfortunately, each of these methods has a drawback (or two).
1. Pointing Out the Answer
As mentors, we actually erode the learning process when we directly reveal the solution to our students. Each snag a student hits is an opportunity for her to grow by fighting through the difficulty and then emerging stronger once she discovers the solution. But these opportunities are lost when we give away the answer too easily.
We make this mistake because it feels helpful to point out the answer. After all, we relieve our student of a burden and allow her to make further progress. We also ease the external pressure we feel to get work done. Nevertheless, we should resist the temptation to accommodate those short-term concerns and instead focus on the long-term goal of developing an experienced, battled-tested engineer.
2. The Monologue
As mentors, we want to share as much of our knowledge as we can. However, verbally conveying a large amount of technical information is rarely effective. We developed our own understanding in gradual steps—not by listening to someone else recite theirs. Therefore, we should be quick to realize when we’re offering more than necessary and save the rest for later.
When we remove the profanity and disdainful tone, this approach turns into referring our student to the documentation (or another resource). Sometimes this is exactly what’s needed. Other times, the student still needs more help. The main problem here is that the student is left swimming in resources on her own. If the student is investigating a completely wrong area, she’ll only waste time and become frustrated.
A Better Approach: Dialogue
Instead of losing the opportunity for the student to learn, we want to guide her toward the solution by nudging her in the right direction. Where a monologue was overbearing and RTFM was negligent, dialogue provides the right level of involvement for both the student and the mentor. Consider this interaction instead:
Student: “I’ve made changes to the code, but I don’t see a change on the screen.”
Teacher: “Let me look. Why should these changes affect what’s being displayed?”
Student: “Well, I’ve changed the attributes of the data that it’s showing.”
Teacher: “OK, it looks like you changed the data correctly. But why would the display update?”
Student: “Hmm. I assumed that this data was directly connected to this view, but let me look into whether or not it actually is.”
Working interactively like this both solves the problem at hand and equips the student to tackle problems in the future. The teacher helps the student. And by taking steps toward the solution herself, the student gains a deep understanding of problem. Even more importantly, active engagement gives her valuable experience. By being involved in the process, she gains both problem-solving skills and confidence, and becomes a valuable team member.