TL;DR: I am sharing the experience of using "teaching" as a "learning" method that can complement the usual approaches of "reading stuff" and "building projects".
A few weeks ago I wrote a 5-part series about using Rust + Warp to create a REST API.
During the process of writing it, I made this comment in a post about The Benefits of Project-Base Learning:
I think the decision is heavily dependent on what you already know. Someone new to programming or new to a language/technology that is wildly different from their previous experiences will have a hard time navigating through the sources required to build a project. There's a minimum required to pull that off, and I think the books, tutorials, streams, and so on are more helpful to reach this threshold. That being said, once you are past this point, I totally agree that building projects is a magnificent approach. And I would also add something else: teaching is an astonishing way to learn things, especially if you wanna go deep.
The comment was a summary of what was going on in my head during the writing of the series. Today, I decided to expand on that.
In my previous experience as an SAP Analyst, I realized there were some complicated things (like Brazilian Taxes—they're a nightmare) that I would not fully understand even after delivering several successful projects in the subject matter. Nothing strange so far. However, things became weird when clients hired me to teach it to their internal team (correctly assuming I knew about it since I was actually doing it). After going through a quick impostor syndrome crisis, I would study the topic for a few nights (because these calls were usually from one week to another) and then something magical happened: things that I used to do without knowing why I was doing them became crystal clear. Surely the previous experience helped. More than that, they were crucial because not only I had fun examples to give (always necessary to break the ice) but also because I knew that what I was saying tied to reality. In short, although I just had learned the "whys", I was already confident regarding the "hows".
Nonetheless, there was something certainly going on regarding the way I studied while preparing for these courses and I kept curious about it, wondering if I could isolate the method.
I kept this in the back of my head but wasn't until I wrote the series of posts I mentioned earlier that I was able to engage in this process of explaining something to someone while also engaging in this self-reflexive effort of paying attention to the process itself, so I could identify why it worked.
Here's what I found out.
First. I wasn't a good note-taker. I'm still not very good, but my MA in Philosophy (don't ask me why an IT guy is doing such a thing) is forcing me to get better. However, when I have to teach/post, I am forced to perform one of the most crucial steps when it comes to taking notes the right way: writing the concepts with my own words in a way it would be intelligible to someone else if I explained it to them. In other words:
- It is not enough to just read, you have to write what you read;
- It is not enough to just write, you must use your own words;
- It is not enough to just write using your own words, it must be intelligible to other people.
Related tip: If you want to get better at taking notes, google the zettelkasten method. Even if it is not for you, it might give you some ideas.
Second. Many times while writing down what I would say in the classroom (or writing a blog post here or somewhere else), I realized I would anticipate questions that someone could ask me, even though I knew they probably wouldn't; and by doing so I was pushing myself to go deeper while looking for these answers.
It's just like that old anecdote: when you are searching for something, you stop looking as soon as you find it. And that's what I did in the projects I worked on: fixed the problem and moved on. In this scenario, however, by not knowing which specific question would be asked, I dove deeper.
Third. The ideal scenario is having all the opportunities: time to read or watch good content, real projects to work on, and a way to share it with someone; but this is not always feasible. If you don't have a project that allows you to push yourself to learn (either because you lack ideas, enthusiasm, whatever) teaching may be a good alternative. Don't get me wrong, this is not a replacement, it is an option.
Fourth. This one might be counterintuitive, especially for the workaholic folks: sometimes not having a deadline might help. If you are already motivated, the opportunity to stretch some goals, to ask one more question, to try one more thing while everything is still fresh in your head allows you to boldly go where no one has gone before.
I don't think that any teaching experience (whatever it may be, writing a blog post, showing a friend how to do something, taking notes for your future self...) can replace other methods, but it is for sure a method worth considering.
Just be careful: when you tell someone you will show them how to do something, people will trust that your content is valid, that what you're saying comes from good sources and/or experience, that your code actually works, and that you spent the time doublechecking the details and so on. That being said, if you are into this to learn (I am obviously not considering those who master what they're sharing in every way, that is, both the whys and the hows), you are not likely to ignore these steps, since you are not only the one teaching but also the first one learning.
But what about you? What do you think?
Cover image by heylagostechie