The ReadME Project Q&A: What you need to know about teaching technical skills

Teaching has bidirectional benefits. Not only does it help others, but it can deepen your own understanding of a topic. Teaching reinforces what you learn, and learning with an eye towards teaching later can improve how you understand and retain material. There are many different ways to teach, ranging from traditional methods like workshops or tutorials to less formal approaches like Twitter threads. Open sourcing your code can even be a form of teaching. 

I gathered a panel of experts to answer your questions about different approaches to sharing knowledge, whether that’s by livestreaming on Twitch, writing blog posts, teaching a class, or something else entirely. But first, let’s meet our panel of experts:

Jerome Hardaway is a senior software engineer at Microsoft, U.S. Air Force veteran, and the executive developer of Vets Who Code, a tuition-free, coding-immersive non-profit that specializes in training veterans. Jerome focuses on helping underrepresented members in the veteran community learn and break into the tech industry.

Cassidy Williams is a Chicago-based developer and head of developer experience at Remote. She pursues her passion for helping people be as awesome as they can be by sharing her programming knowledge through frequent talks at technical conferences, live streams, her email newsletter, and through meme-making.

Anthony Sottile is a staff software engineer at Sentry working on developer productivity. He shares his knowledge through his popular Twitch channel, where he live streams his work on open source projects. His open source projects include pre-commit, babi, and flake8.

Klint: Let’s start at the beginning. It can be really intimidating to put yourself out there regardless of whether you’re teaching an online class or giving a talk. How do you know when you’re ready?

Anthony: I need to exercise what I learn before I teach it. I learn technologies by using them in projects—often more than one project—so I can get a real sense of the sorts of stumbling blocks people might face. I’m not comfortable teaching until I’ve faced some adversity.

Jerome: I also need to find a bit of adversity before I teach the subject, to understand the “gotchas” a student might run into. Maybe it’s the military mindset in me: I would want someone with more experience than me leading me into battle, so I don’t teach anything I don’t have real-world experience working with first, which means putting something in production that users can critique. I want to be confident in answering questions or correcting misconceptions or errors. It’s hard to do that without getting your hands dirty.

Cassidy: Obviously you need to understand something before you can teach it. But you might be able to start teaching something earlier than you think. You can often give a talk or teach a subject as long as the target audience knows a little less than you do. A lot of times, beginner coders are good at teaching other beginners because they’re teaching from a beginner’s mindset. Likewise, senior-level engineers are often better suited to teaching other senior-level engineers, and mid-level engineers are often better at teaching other mid-level engineers. Teaching people close to your own level makes sense because you’re less likely to assume someone knows something that’s actually a bit above their level of understanding.

Klint: How do you prepare to teach a topic?

Cassidy: I’m an avid note-taker. I take notes on everything: Sometimes it’s a single thought or sometimes it’s an essay’s worth. Writing everything down makes it relatively easy to convert my notes into slides for a talk.

Jerome: Yes, it’s absolutely all about notes. I have like 40 notebooks. Moleskine should sponsor me. A lot of teaching comes from documenting how you learned, then turning that into something tangible and manicured that you can share with others. You need to remember the problems you faced, you need to remember the metaphors or ideas that helped you finally understand something. Documenting my experience is the way I do that.

Anthony: For me, if it’s a topic I don’t already feel like an expert in, I’ll do supplemental research before doing a stream or making a video. For example, I read the documentation and look at other people’s projects to gain more context.

Klint: It sounds like being ready has as much to do with your comfort-level with the material as it does with your knowledge of the material. Given the rampant imposter syndrome in the industry, how can you build confidence in your ability to teach? 

Anthony: Lower the stakes. For example, you can start by giving a presentation or workshop internally at your own company. Or just start with a presentation for your own team. Streaming is actually also pretty low stakes because you probably won’t start out with a large audience, so you can build confidence as you build a following.

Jerome: I try out new strategies for teaching during one-on-one’s with the people I mentor. There’s much less pressure when you’re working with one person at a time rather than a whole class, and it’s easier to adapt on-the-fly depending on their response and needs. If I find something works well with multiple individuals, then I know it will probably work in the classroom..

Cassidy: I would also remind folks that it helps to have a plan for when things go wrong. You don’t want to spend too long dwelling on the negative, but, once you’re ready to make the jump to giving a talk or teaching a class, it helps to have some strategies in mind. For example, you probably won’t be able to answer every question you’ll be asked. You need to be comfortable saying “I don’t know that answer. I need to do more research.” 

At some point in your career, there will be someone who disagrees with what you’re saying or just doesn’t like what you’re saying. With the latter example,  often the best thing to do is say: “Please hold that thought so we can discuss afterward.” Taking a conversation offline is a great way to diffuse a situation where someone is being rude or argumentative.

Klint: I’m gonna go out on a limb here and guess that sometimes people will point out things that are actually factually or technically incorrect in a lesson—hopefully politely and after a talk, stream, or lesson is over. What do you do when you realize you’ve been teaching something that’s, well, wrong?

Anthony:  I do my best to alert viewers that the content is outdated and usually try to produce new, correct content as well. Sometimes I make videos where I tell people how I used to do things and the reasons I did them that way, then explain why I changed my mind. I’ve had to do this a few times. Fortunately, the YouTube algorithm really seems to like “I screwed up” videos.

Jerome: Firstly, I have the honor of teaching veterans, who value being direct and polite, but when I’m wrong I use it as a live learning experience. It builds trust with the student when you make mistakes and you work with them to correct the issue. Some of the best classes I’ve had recently involve us seeing something wrong and working through the error together. They see the process, recognize it, know it’s OK to not be perfect, and understand the things that you know come from the cultivation of your past mistakes and efforts, not because you are smarter than them. That’s as much a leadership thing as it is a teacher thing.

Klint: Any final tips before we sign off?

Jerome:  Build templates for your teaching processes. A lot of my mistakes early on involved trying to recreate the vehicle for the content each time, which took time away from the content itself. Make templates you can grab and place the subject matter into.

Anthony: One key is to figure out what learning style works best for you, and then focus on that. I don’t learn well from books. I learn by doing. So all my videos are based on projects.

Cassidy: Don’t forget that perfect is the enemy of good! You can always improve as you work. Just start producing learning content, and the improvements will come with time.

The ReadME Project is a GitHub platform dedicated to highlighting the best from the open source software community—the people and tech behind projects you use every day. Sign up for a monthly newsletter to receive new stories, best practices and opinions developed for The ReadME Project, as well as great listens and reads from around the community.

Written by

Klint Finley

@klintron