If you want to get really good at something, teach it to a total beginner.
Photo by Will Porada on Unsplash.
If I asked you to teach me what a stop sign is, your first instinct might be to say something like, "It's a traffic sign that tells you when to stop your car." If I asked you to teach a kid what a stop sign is, though, they'd probably ask you questions like:
- What's traffic?
- What's a car? (Depending on how old the kid is)
- Why is it there?
- Why do you have to stop?
Whenever you teach something to a total beginner who has no context about what you're talking about, regardless of their intelligence or curiosity, you're forced to distill a subject to its most essential pieces. Teaching a beginner requires ditching as much jargon as you can, remembering not to take their understanding of foundational concepts for granted, and breaking things down in a way that gives them the most important and useful information without giving them too much detail to overwhelm them. For example, if you describe a stop sign as "A red thing on a pole" (in America), that's pretty easy to understand but isn't very useful or accurate. If you hand them a book of traffic laws, you've given them accurate information that's not very easy to understand. "Less, but better," as the industrial designer Dieter Rams used to say.
When I was in my third year of being a developer, I took on my first mentee, a coworker named Nick who was a business analyst hoping to become a web developer. In addition to all of the self-study he was doing through websites like Treehouse (I don't think freeCodeCamp existed yet), I was using our production applications to teach him real world web development. For me, the biggest shock of getting my first developer job was all the stuff that the "learn to code" resources leave out: Git, Agile, deployment, production bugs, legacy code, and managing your time in a sprint.
I started giving Nick small bugs to fix in the codebase to get him some practice with that stuff. Each time, he would come to me with a series of questions that ended up teaching me quite a lot. There are so many things towards the beginning of our career that we just accept as "the way things are" and never really stop to think about why. I remember one of our conversations going like this:
Nick: "This HTML file isn't showing up when I run the application."
Me: "Oh, you probably need to add it to our Gulp build."
Nick: "What's Gulp?"
Me: "It's our...thing...to build the app." (I had no idea at that point how Gulp actually worked.)
Nick: "What does build mean?"
Me: "Like minifying and concatenating everything."
Nick: "What are minifying and concatenating?"
Me: "It's like removing everything unnecessary and putting it all in one big file instead of a bunch of little files."
Nick: "Okay. So why do we use Gulp?"
Me: "Uhhh I have no idea. Let me go find out."
I would leave these conversations with a bunch of things I needed to explore. Being just a few years in myself, I had only learned things at a very shallow level, just enough to survive the job. Being responsible for teaching Nick forced me to grow. I had to think through all of the pieces of our application and be able to explain why things were the way they were (well, as best I could -- we all know some things in a codebase are just lost in time). I've had many similar experiences in the years that followed.
For this reason, I can't encourage you enough to create beginner content. This might not mean blog articles or YouTube videos, it might just be the onboarding documentation on your team's wiki. It might be lunch and learn sessions with your junior coworkers. If you are hoping to become a developer advocate or just wanting to create content to grow your career, beginner content is an excellent practice. Find the sweet spot of a topic complex enough to be difficult to teach, but even at its most basic level would be useful for beginners. React hooks are a great example of this; you can go really deep on that topic, but the fundamentals are crucial for beginners.
This is one of the reasons that I actually love being in the identity space for my day job. The most difficult podcast I've ever done was when I was on CodeNewbie to talk about auth for beginners. First of all, this was kind of a bucket list item for me, as I've been a fan of Saron for a long time now. I was very nervous talking to her right off the bat. What made the podcast so difficult though was how challenging it was to remain accurate while not throwing too much jargon at the audience. You wouldn't know it because their editing is so good, but I actually had to ask them to remove a couple of lines that where my attempts to simplify some of the identity buzzwords ended up being inaccurate because I left out something crucial.
At any rate, that podcast taught me a valuable lesson: the best way to truly be able to abstract a subject for beginners is to know it deeply. Those opportunities don't usually just fall into our laps, we have to seek them out. As you go through this week, try to find some opportunities to teach something you're working on to a beginner. That could be a coworker or it could be a random stranger on the Internet through a blog or a video. Give it a try and let me know how it goes. Did they ask you questions? What did you learn?
Oh, by the way, Nick did make the leap to an official developer and has never looked back. It was one of the most gratifying things I've been a part of and got me hooked on teaching and mentoring from that point on.