00:00:30.240
Likes to smoke meat apparently, in his free time. He also does some other things like Ruby gems and Ruby docs. I don't know if you guys have heard of those things. Ruby docs is pretty cool, I suppose. Look for him on the internet; his name is Dr. Brain, and he's going to talk to you about something fascinating. A round of applause, please.
00:00:51.600
Hello, I’m here to talk about technical mentorship. But first, I work for Fastly, and we're the smartest CDN on the planet. I would say some more awesome things about Fastly and why you should use it, but my marketing training is scheduled for next Wednesday or Thursday, so I don't know how to say those things. We're also hiring, and it's a super awesome place to work. It's the best place that I've ever worked at. I've got a few Fastly stickers if you want to ask questions about my talk or Fastly later. They also have an excellent conference policy. So, if you go to talk at a conference and mention Fastly and wear some Fastly clothes, then they pay for it, and apparently, there's no limit on the number of conferences you can speak at. I haven't tested this out yet, though. This talk is only about technical mentoring, which is something you can do every day. This is not a talk about career or professional mentorship.
00:01:39.680
In technical mentorship, the roles of the teacher and the student may not always allow you the freedom to willingly choose who your partner is. The scope of technical mentorship is usually just work-related: the things in your projects you're building. You don't typically have much discussion of broader issues that might arise, like workplace troubles, harassment, or career advancement skills. What I want you to think about is how we can transfer technical knowledge and skills most effectively. It takes just as much work to improve your technical teaching skills as it does to improve your technical skills for yourself.
00:02:06.880
Before we start, though, what is programming about? What are we doing when we sit at the keyboard typing away? The product of our work consists of writing down some kind of algorithm that completes a task. We have all the steps lined up so that, when the computer runs it, it can perform the task in an automatic way for us. As we're writing this, we need to consider all the problems we have and figure out how to handle them so that everything will work correctly when we use this.
00:02:37.600
There's another piece of programming: programs must be written for people to read and only incidentally for machines to execute. We are also communicating all of this with our co-workers, users, and fellow contributors. To be successful at programming, we must also communicate our thoughts in a way we can mutually understand. By changing the way we write down our work, we may make it easier or more difficult to follow. The tests we write, the way we commit our code, and the way we document our work all affect how the programs we write are understood by the people who are working with it.
00:03:11.199
Good technical mentorship also smooths out this process. It helps us build the skills of a less familiar person in a positive way. If you're only going to take one thing away from this talk, this should be it: no touching. I will talk about the obvious kinds of touching that you shouldn't be doing. We should all have that down by now. If you want an example of wrong touching, you can search for Joe Biden touching. There are tons of examples of what not to do. But this also applies to the computer and the keyboard.
00:03:45.280
Don't touch their screen when you need to point something out, and never take away their keyboard or trackpad. Doing so reinforces the idea that the person you're working with can't do the task themselves. More importantly, by taking these actions, you prevent the person from developing their muscle memory. When you take away the keyboard, you're preventing them from doing the work, and when they're doing the work, they have a greatly enhanced ability to learn. This also helps the person you're working with build confidence in their work. When they encounter similar problems later, they'll have the experience of having worked through them with you, allowing them to tackle challenges independently.
00:04:50.799
If you’re not successfully communicating what you want your partner to do or what they should type or write, write it out for them so they can repeat it back. For example, when I worked with a student at Ada, I would often say, 'No, that's not quite right.' Then I would open my computer and show them what I wanted their code to look like, writing it out so they wouldn’t have to copy it down. This provides reinforcement for their learning. This method also works when reading through documentation together to clarify how to approach a task.
00:05:44.800
Sometimes, however, it is necessary to take control. If you're unclear on something they've said, you may need to go through their reasoning with them to facilitate understanding. Before doing this, ask for permission and explain why you need to take that action. For instance, you might say: 'I see that you wrote these two things, but there's one way up here, and another way down here. Can I scroll back and forth to compare these two to think about it a little further?' Once you’ve clarified the information, return control back to your partner as quickly as possible so they can get back to their learning.
00:06:07.558
When someone comes to you for help, listen to what they have to say. The problem they describe may not be the actual problem at hand; they might be giving subtle clues that hint at the solution they don't realize they possess. Often, all you may need to do is provide a small piece of guidance to help them get back on track. By listening carefully, you minimize the amount of touching you have to do with their computer. Even if you think you know what the problem is, don't interrupt them while they finish explaining. Instead, listen actively to build understanding between you and your partner. Confirm that you've heard and understood them by restating what they've said in your own words to ensure you have correctly grasped the problem.
00:07:05.440
Also, do not assume that your understanding of the situation is complete or correct. It’s essential not to assume that your partner's understanding of the problem is either. Recognize your assumptions while listening. You might start to think that you have a better solution than they do, only to realize later that their idea is indeed better. For example, at Ada, I often got asked how to implement a specific feature and would describe a few different ways to do so. Then a student would suggest a solution that turned out to be simpler or more effective because they were currently engaged with the problem.
00:07:50.160
Overall, I have more experience than the students, but many times their ideas would be better because they are in the midst of solving their problem, while I may not have considered it for over a year. In addition to cultivating a mutual understanding, ask questions that provoke realizations in your partner. This approach helps new programmers identify problems for themselves. When you can see the problem clearly but your partner cannot, ask leading questions that are immediately actionable. Sometimes this method involves playing the role of a rubber duck, where you ask them to explain their problem, and you help them walk through possible solutions together.
00:08:10.240
When research or debugging, ask questions like: 'What changes did you make since the last commit?' or 'Have you tried reseeding the database?' By using debugging techniques and asking thoughtful questions, you help guide your partner to think critically. If they have a checklist of common fixes or procedures they use, encourage them to follow that approach. This can help streamline the process and reinforce their understanding.
00:09:02.080
Your primary goal should always be to fix the problem they initially approached you about. Avoid distractions that could divert them away from achieving their goal. In a classroom environment, your priority should be to help the student overcome whatever obstacle they're facing so that they can return to their assignment. In a workplace setting, this means enabling your co-workers to continue working independently. Once you've resolved the immediate problem and they’re ready to move on, only then should you bring up potentially distracting topics. For example, if they have an issue with indentation or formatting, or if you know an editor trick that could help them work more efficiently, save that feedback for later once they have a solid understanding.
00:09:53.920
When explaining a new concept, strive to keep it simple. Break it down into manageable pieces. In doing this, be careful not to trigger questions that may distract from the main goal at hand. It is a delicate balance—you don't want to withhold relevant information from your partner, which could come off as unkind, but you also want to present ideas in digestible pieces they can easily understand and integrate with their existing knowledge. A vital part of keeping your explanation straightforward is to limit distractions. If your partner asks how something works and it’s a broad topic, respond with clarifying questions like: 'Which part do you mean?' or 'What are you currently working on?'—this way you can focus on relaying the critical information they need first.
00:10:48.080
Once they grasp the essential concepts, you can then provide additional insights or tips that may benefit them in the future. Remember, say 'I don’t know' whenever you encounter something you’re unsure about. Even if you possess more domain knowledge than the person you're mentoring, this doesn’t always translate into having all the answers immediately. By admitting when you don’t know something, or by being uncertain, you create an environment that encourages your partner to feel comfortable approaching you when they need help.
00:11:34.080
There is also the phenomenon of knowledge that only seems obvious to ourselves. Ray, who is sitting down in front, once said there are two types of knowledge: the kind that is obvious and the kind that we have yet to acquire. Remember that when you are familiar with something, there are many automatic behaviors you perform that may not be immediately apparent. By saying 'I don't know,' you reaffirm that it's okay for someone not to understand certain concepts right away.
00:12:14.560
Recently, Justin Searles wrote a blog post about setting up a Capybara test. He highlighted the complexity of typical test setups for Rails applications, detailing 22 steps he took just to get one test working—not including the steps it took to write the test itself. This complexity is common across many skills we develop; it becomes easy to forget all these essential steps until you must explain them to someone new.
00:12:58.000
Emily Clarice, a relatively new developer, shared how one engineering mindset impeded her: the belief that she would never catch up to what others knew. In her post, she discussed varying metrics for evaluating success for programmers, as compared to other fields. By acknowledging gaps in your knowledge and demonstrating how you learn, you can reinforce to your partner that they too can excel as a great developer without needing to acquire precisely the same skills you have.
00:13:53.519
When a program is not written the way you expect or prefer, start by asking questions to understand why it was written that way, rather than rushing to criticism. When someone is new, they may not know how to properly structure their program and might be aware of this fact. By taking the time to understand their reasoning, you can offer constructive feedback to facilitate their growth, helping them advance from their current understanding to the knowledge they aspire to achieve.
00:14:57.760
Provide feedback that enables the most significant improvement in the project first. For instance, can there be substantial enhancements in runtime? Will utilizing pre-existing functions help reduce duplication? These considerations should be addressed first. It's also acceptable to overlook minor issues, especially in a learning environment. If there are typos that do not hinder program functionality, that’s acceptable. Your primary concern should be determining if the code works, followed by assessing if the author understands how and why it works.
00:15:42.640
Ultimately, while code must be free of bugs and perform efficiently, it may not be well-factored or styled according to your preferences. In situations where a student has not mastered something yet, I think it’s reasonable to let some things slide as learning is part of the process. When you focus criticism on what truly matters, you can foster your partner's confidence while still maintaining quality.
00:16:22.240
As you provide explanations, be mindful to avoid insulting your partner's intelligence, particularly if their project involves knowledge they lack. Create a safe space for learning, welcome various ideas, and encourage exploration of different approaches while allowing for mistakes to nurture an environment conducive to success.
00:17:10.080
Eliminate as many traps and pitfalls as possible, guiding your partners to avoid blind alleys that lead to trouble. Share resources such as documentation, libraries, and tools that assist them in their learning journey. Evaluate how long it takes to set up your development environment and minimize these steps to facilitate quicker onboarding for newcomers to your project.
00:18:10.919
Always stay aware of the emotional states of your partners when you assist them. It's clear when they may struggle to keep up, feel confused, or if frustration begins to build. Offering empathy is vital; frustration often exacerbates self-doubt, which can be especially distracting for new developers. When you sense rising tensions, suggest taking a break and frame it positively—perhaps by saying, 'I’m thirsty; can we stop for a bit?' During breaks, ensure both you and your partner refresh, as this will help recharge your minds and allow for clearer thinking when you regroup.
00:19:04.719
While it’s crucial to avoid being overly present in their process, it's also acceptable to step away for a while, allowing your partner to work through challenges independently. It's perfectly acceptable to assist them in getting unstuck and then suggest possible alternative paths they can explore on their own.
00:20:03.760
As you think through a problem, it's helpful to build a mental model of how you want your program to work. You likely have an intuitive understanding based on past experiences of how all the different pieces fit together, unlike someone unfamiliar with your work. If you’re working with a novice, they may struggle to visualize more than a few steps ahead. By providing thinking tools, you can assist them in constructing their mental models and mapping their understanding.
00:21:10.320
Visual aids can be a helpful tool in discussions about problems; drawing database schemas, flowcharts, and communication diagrams can clarify ideas. Using visuals to reinforce your points facilitates discussion and exploration of changes. Alternatively, physical analogies can aid understanding. For instance, when discussing the clustering feature at Fastly—a process where a request checks nearby cache nodes before going to the origin server—I might compare it to borrowing a cup of sugar from a neighbor when I'm out.
00:22:04.240
These analogies help visualize the steps involved in your program, enhancing understanding. Moreover, knowing the right keywords to find answers on platforms like Stack Overflow is a crucial skill. Teach your partner how to locate information that will help them improve their problem-solving skills.
00:23:06.960
Continuously cultivate good habits in your partner. Share the small practices that contribute to your effectiveness—whether it’s setting up your development environment or your coding conventions. Discuss the strengths and weaknesses of various approaches and share your testing practices thoroughly, pointing out excellent testing examples they can refer to.
00:24:04.240
If they’re writing a test that becomes too complex, guide them to deconstruct it into smaller portions. Additionally, ensure that any tests they write adequately cover their implementation, explaining the expected behaviors and potential edge cases they might have missed.
00:25:00.000
Document essential practices for contributing to your projects. Provide a guide for contributing and debugging to simplify onboarding for new people. Consider creating checklists for repetitive tasks to standardize processes and pave the way for automation that will minimize the likelihood of errors. Proper documentation allows you to help others without the need for constant direct communication.
00:26:04.960
Also, teach the importance of good committed practices. I favor small commits as they ensure I stay organized and can backtrack easily if necessary. After helping someone resolve an issue and getting their code working, I ensure they make a commit. This way, their subsequent tasks build off a stable base, simplifying identifying any issues that arise.
00:26:27.760
Finally, guide your partner on how to structure good commit messages, maintaining an organized history that’s easy to navigate. Help set expectations regarding code reviews by highlighting areas of the code that are critical and require thorough scrutiny.
00:27:01.720
Utilize automation through continuous integration for automatic checks. This way, they can upload their code and see if it passes tests without always needing assistance. When your partner embarks on a task that is new to them, aid them in estimating the time required, as well as discussing potential challenges they may encounter along the way.
00:27:47.440
Assisting them in learning to evaluate how long to work stuck on a task before turning to you for help fosters independence and builds their problem-solving skills. Clearly establish the scope of their tasks by indicating which areas they should and shouldn’t touch, and provide an idea of the task's difficulty.
00:28:41.440
Toward the end of the Ada classroom time, the students work on a capstone project over four weeks. This undertaking can feel daunting after only five months of classes. I've supported students in breaking their projects down into smaller tasks, ranking them by impact, difficulty, or necessity to facilitate more efficient progress.
00:29:56.080
No one wants to remain the noob until someone new comes along. Leaving a peer stuck disrespects the skills and knowledge they’ve gained. Instead, work together as equals, collaborating and sharing expertise to create something meaningful.
00:30:43.760
Share both your successes and failures. Own your mistakes and encourage your partner to move beyond theirs. We want to build something great together, not climb over each other to reach the top. As you collaborate as a team, nurture a culture of sharing. Encourage your partner to discuss their understanding, update documentation, and provide feedback on shared experiences.
00:31:25.920
Just because your partner may not be an expert doesn’t mean they lack valuable insights. A fresh outlook can help even seasoned professionals reconsider familiar issues and approach matters from a new perspective. Recognize the contributions of your colleagues. We seldom work in isolation, so it’s essential to credit those around us, regardless of relative skill levels.
00:32:25.920
Never pretend to be knowledgeable about something when you’re not. I often told students when I didn’t know how to perform a fundamental task, and together we would search for solutions. Learning to utilize Google is one of my most frequently used professional skills; I forget numerous details daily and often need to consult more knowledgeable colleagues to jog my memory.
00:33:26.560
Throughout your time spent working with others, you will make mistakes. Own up to those errors and offer sincere apologies when necessary. A simple, 'I’m sorry,' goes a long way in fostering trust and demonstrating that it’s acceptable to make mistakes, whether in touching a keyboard incorrectly or accidentally brushing against someone.
00:34:20.000
If you find yourself interrupting your partner while they're articulating their ideas, stop and acknowledge it. Say something like, 'I'm sorry, you were saying,' and then listen attentively. Perhaps they expressed something you misunderstood or failed to communicate clearly.
00:35:23.760
Key elements include acknowledging your mistakes and recognizing how you can enhance your performance going forward. There are many opportunities to apply these skills. I’ve utilized these approaches in my collaboration with others to enhance understanding and ensure I do not waste their time when I’m navigating new projects.
00:36:40.480
By improving my understanding, I can prevent myself from becoming overwhelmed when faced with new challenges. Onboarding new employees is an excellent opportunity to implement these strategies, regardless of how experienced the newcomer may be; they are still new to your specific workflow.
00:37:33.720
Whenever someone engages with a new system, they may have experience, but they’re unfamiliar with the unique intricacies of your process. As you partner with someone less experienced, by assuring them a solid experience, you invest in each other and avoid isolating knowledge silos.
00:38:15.200
Finally, while teaching younger developers, such as those I taught at Ada Developers Academy, always consider their emotional well-being. Their questions do not aim to annoy you; they arise from a legitimate desire to learn.
00:38:37.920
By employing the techniques I've shared today, we can help facilitate smoother transitions for newcomers between different teams—enabling individuals with interests in various company sectors to explore diverse roles. Encouraging this kind of sharing benefits everyone, as it distributes knowledge evenly across your organization.
00:39:49.360
In conclusion, I want to share a remark from an Ada student who indicated that changing my approach to technical mentorship had an essential impact on my effectiveness. They described conversations with me as akin to the car ride scene in The Matrix, where they learn so much about the world they wouldn’t have grasped on their own.
00:40:07.760
However, they also mentioned that when you push someone from that comfort zone, they end up in unfamiliar territory, needing to navigate through new challenges. Since that time, I’ve been more mindful of packing a metaphorical lunch and ensuring they feel equipped to tackle the unknown ahead.
00:40:35.360
I would like to thank several contributors: Liz Rush for her input on defining technical mentorship, Kat Husselton for the slide regarding allowing your partner to work independently, and Elizabeth Aselton for sharing insights about my past failures as a teaching assistant. Additionally, I owe gratitude to Sing Way for our ongoing discussions that shaped this talk's framework, my colleagues at Fastly for their feedback after I delivered this presentation at an engineering summit, and finally, the Ada students for creating an environment where I could grow and learn.
