Thread by @JoshWComeau

Are you interested in teaching stuff to developers? Maybe through a blog, or a workshop, or an online course?

🧵 This thread is a quick summary of some of the most-critical stuff I've learned, over years of blogging, teaching at a bootcamp, and working in edtech at Khan Academy.

I believe that there are two categories of learning: active and passive.

Active learning means that the learner is doing something. They're solving a problem, writing some code, playing with an example. Passive learning is watching a video, listening to a lecturer.

Which one is better? Well, I think active learning is probably more effective, but it's also more draining. Nonstop active learning is *exhausting*.

I like to treat it like interval training: I intersperse both types, so that we're constantly hopping between them.

In my course, most videos are short, less than 5 minutes. This lets us bounce between active/passive, but it has another benefit: it's easier to stay focused.

Most of us are bad at sustaining attention. Our mind wanders during long videos. So I keep them short.

By moving between content types (an article, then an exercise, then a video, then a minigame…), you're always doing something different.

If you stick with a single content type, learners will go on "autopilot", tuning important stuff out.

I want my course to be fun. In fact, the *most* important thing is that people enjoy it! A densely-packed super-educational course is of zero value if people stop after the 2nd lesson because they find it boring.

"Fun" doesn't have to be empty calories, either! The very first lesson in my CSS course is about terminology, an inherently dry (but important!) topic, so I make it fun with a novel minigame that involves selecting the relevant bit with your mouse:

For blog posts, it's important to realize that readers have made zero investment—if your article doesn't provide value and/or entertainment right away, they'll bounce.

I try and prioritize quick wins, even if it comes at the expense of thoroughness.

Quick wins in general are super important. The learner should learn something practical & valuable as early as possible.

I used this trick in this very thread! By tweet #3, I had already shared one of the most eye-opening realizations I've had in my journey (active vs. passive).

Whenever possible, try and take advantage of stuff the learner already knows.

My course is called "CSS for JavaScript Developers", and I leverage the heck out of the fact that the learner knows JS. For example, I explain the cascade by drawing an analogy to the spread operator.

Analogies are great because you can copy/paste a mental model they already have. Way easier than building a new one from scratch!

But, you need to take care to make sure they understand the differences. Otherwise, they'll have subtle misconceptions which'll cause problems later.

I'm naturally a bit quirky, and I make zero attempt to hide this in my content 😄

I learned this straight from Sal Khan, founder of Khan Academy. He's intentionally a bit weird in his videos, because it makes the lessons more memorable (which means better retention!)

I don't try and adopt a sage "teacher" persona, nor do I try and come off as super polished and professional. I am who I am, and I think my content is stronger because of it. Plus, it's way easier for me to sustain long-term, since I'm not pretending to be someone I'm not.

The most effective way to remember something is to use spaced repetition (ncase.me/remember/).

When we teach something over weeks (like in a course), we should resurface older concepts from time to time, to make sure they aren't forgotten.

When it comes to programming, we often expect novices to learn two distinct things at once:

• A technical concept (what it does, how it works)
• Its syntax (how to write the code to apply the concept)

If possible, separate these two things at first!

A good way to do this is through a Parsons problem: The learner is given all the code, but in the wrong order, and they have to rearrange it.

They can focus exclusively on the concept, and not have to worry about remembering the syntax (yet).

That “Parsons Problem” screenshot is from a *fantastic*, meticulously-researched book on teaching technical topics. It's called Teaching Tech Together, by Greg Wilson. You can read it here: teachtogether.tech

Another great resource is Eddie Woo's YouTube channel: youtube.com/channel/UCq0EG…

Eddie is an Australian high-school maths teacher, and he's *exceptional*. You can learn so much from watching him teach. He also has some "meta" videos about teaching!

To be clear, I am not an expert at this stuff. I'm learning as I go. But: I know that I've become much more competent at teaching over these past few years, and hopefully this thread can serve as a bit of a shortcut for folks just getting started 😄