I’ve been reviewing some coding skills in my spare time to improve the content and coursework I create for my day job.

As part of my practice, I’ve been talking to myself.

Here’s one example:

“I need to turn this text into a link, so [as I’m typing out the code] I need to wrap this header element in an anchor tag and add the hypertext reference attribute to it and set it equal to the hyperlink I need to direct my audience to. Oh, don’t forget to add the target attribute and set it equal to blank so it’ll open in a new tab.”¹

It’s more tedious and time-consuming than simply typing out the code. But the point is to understand the concepts behind what I’m doing, not just to write functional code as quickly as possible. (If I wanted to do that, I’d just have Claude do it for me…)

Teaching someone else—even if you’re teaching yourself by talking out loud—is one of the best ways to prove you know something. When you force yourself to explain something out loud, you learn where the gaps in your knowledge are, which then signals what you need to review. Then, when you come to the same scenario again, you can see if you’ve acquired the necessary ability to explain your former knowledge gap.²

This is active recall: talking or writing out something you’ve learned in your own words, and it’s how I’ve been approaching certain aspects of training at work. Rather than having everyone watch videos or read through course SCORM files, we’re testing employees’ abilities to talk through features.

It starts with review, of course—you still need content they can reference at the beginning of the learning process. But that’s where L&D often falls short. We equate content delivery with learning. And, obviously, that’s not true.³

But the proof of learning comes when they’re forced to talk it out and get graded on their delivery.

There’s no punishment for getting things wrong. But we know for certain where the gaps in understanding are, what needs review and further study. Or we learn that we, the L&D practitioners, missed something in the initial teaching and have to fill it in.

Talk out what you’re learning. If you can explain it to someone else (or yourself)—out loud—there’s a good chance you’ve grasped the concept.

---

1. I’m aware that this is extraordinarily basic HTML code for all you web developers out there. But the point is the practice of talking it out, not how advanced the code is. ↩︎
2. My favorite book on this topic was actually written to help college students improve test scores. Check out Cal Newport’s How to Become a Straight-A Student. It’s not just for undergrads. ↩︎
3. Again, I have to point out that this is why most online learning (e.g., MasterClass, Udemy, and most corporate training) doesn’t work. Consuming information isn’t learning. It’s part of it, sure, but only the retention and understanding of that information actually matter. And the only truly effective way to test this is through active recall, which is exactly what I’m doing when I talk out my code. And it’s what we’re doing when we have people talk through our product. ↩︎