Learning By Preparing To Teach

I spent years as a technical trainer and as a result, I spent a lot of my time learning new things and also figuring out how to explain those things to people with less experience.

At the beginning, I would spend a lot of time learning the new language, tool or framework and then I would go about figuring out how I wanted to approach teaching it. As I got more experience with both teaching and with learning new things, I found that I was able to combine these efforts. I have carried that with me even though training is no longer my primary job.

I'm currently working on full-stack JavaScript solutions, so learning new frameworks, libraries and tools is pretty much a daily part of my life. I've found the fastest way to learn new technology is to approach it as if I'm going to teach a class on it. Even without any actual students, teaching is still the best way I know to learn something new.

I thought I'd share part of my process here in the hopes that it might help you learn new things faster and with more depth. For the rest of this post, I'll refer to the thing I want to learn as a library so I don't have to call it the thing or something too verbose.

Get Familiar

Step one is to get familiar with the library. Since I typically have a need to learn this library, I generally start with some context of what it is and why I'm interested in it. Keeping that context in mind, I will go to the github page or home page and look at any introductory material available. Tutorials, introductory videos, live demos running in JSBin are all great ways to get familiar. From there, I'll typically open a JSBin or Webpackbin, or I'll spin up a sample project on my machine so I can get my hands dirty. At this point, I'll typically run through a tutorial or two and then start making my own changes from there. I'll see what happens if I change x and look at the api docs to see why I need y. Once I feel like I have a handle on what the library has to offer, it's time to start preparing for that class that may or may not happen.

Begin With The End In Mind

Now that I'm familiar, I come up with a loose plan for a sample application I would build with a class. I try to keep the sample app simple and attainable while also thinking about how it will include the major points that need to be covered. I say a loose plan because as I work through the individual topics I need to cover, I will refine and adjust the plan for the app. I tend to view the app as something that will be along the lines of a final project for my imaginary class.

Create an Outline

With a context, a general feel for the library and a loose "final project" goal in mind, I start an outline. The outline starts with an introduction step. The introduction outlines how I would start off the class. It would be the basic talking points to introduce the library, explain the goals of the class and try to capture the essence of the library.

Once there is a general introduction, I create steps for each basic concept I want to cover with relevant details. I will also make notes for myself about the example(s) I want to create for this concept. For each core concept, make sure the outline includes some key points and how you would explain this to somebody else. Drawing comparisons and identifying analogies for items is a great way to think about how to explain something.

Create examples

Once I have one or more steps that will need example code, I start creating those examples. I try to keep initial examples as focused on one idea at a time as possible. Once there are several individual examples that can be combined to achieve something new, I will create an example that pulls together the previous concepts.

Refine

This process is a continuous cycle of refinements. As I create example code, I go back and add notes and make changes to the outline. Sometimes, that informs the way I create examples and the combinations I end up with for the collective examples. Those changes will take me back to the outline, and around and around it goes. I will also revisit the final project based on refinements to make sure it includes the things it should. The key to this process is that at each step, I keep potential questions in mind. In many cases, these hypothetical questions require that I dive a little deeper into the library API. This gives me more understanding, causes me to update the outline and in many cases creates the need for a different example. If those examples create more questions that need more research, then I get to learn more.

Since there is probably not an actual class, I can choose how far down the rabbit hole to go. I also always have the option to revisit this process down the road, so I can reach a certain level of proficiency, get back to work and several months later, I can come back to my outline and sample code and dive deeper into those things I didn't need the first time through.

A Hidden Bonus

As an added bonus of having all of this sample work done, is that when there is a new version of the library, you can always copy the old examples, upgrade your library and use the working examples to figure out how you're going to handle breaking changes and work in enhancements.

Teaching something is one of, if not the, best way to learn something. If you can use the preparation approach to reach a decent level of understanding, why not take it one step further and teach somebody. You don't have to use your outline or go through all of the example code you created, and you certainly don't need to be in a formal classroom setting. Show your co-workers how to work with this new library, present it at a meetup group, write a blog post or create a training video for YouTube. This allows you to give back while strengthening your own skill set.

Some Final Thoughts

I try to do as much as I can from scratch. When I mentioned trying to capture the essence of the library in the outline introduction, my goal there is to gain a deep enough understanding that I can do this in my own words. That being said, if I were to ever teach a class, I'd probably quote the creators of the library because they've probably done a better job than I would. This is more about the thought exercise... this whole approach is about being forced to think about something new beyond just being able to get some work done. This is truly about understanding, not about learning the basics of an API or being able to copy and paste code.

This approach might not be for everybody, but if you have an inclination to explain things to others or you have been looking for a different way to learn things quickly in a rapidly changing field, give it a shot and comment here to let me know how it worked out for you.