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
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 😄
• • •
Missing some Tweet in this thread? You can try to
force a refresh
From March 2020 to ~October 2020, I wasn't really able to use a keyboard/mouse.
I've been pretty public about how I worked around it (joshwcomeau.com/blog/hands-fre…), but I haven't been as public about how I overcame it.
🧵 This thread is about my personal experience with RSI.
This is a story about my own experience, not a tutorial for how to solve RSI. Everyone's different, and just because something worked for me doesn't mean it'll work for you.
Please read all the way through before trying anything.
[cw medical stuff / surgery discussion]
In March 2020, I injured my left arm. Certain activities, like typing, would cause a burning pain in the elbow, and occasionally the wrist or fingers.
In May 2020, the same thing started happening in my right arm.
Around this time tomorrow (10AM EST), I'll be launching my first product as an indie hacker, CSS for JavaScript Devs (css-for-js.dev).
It has been one heck of a ride 😅. In this thread, I wanna share what the journey's been like ✨
In early 2020, I developed an RSI that made it impossible to use a keyboard/mouse. I spent months not using a computer at all, and then months training myself to code with dictation and an eye-tracker.
It's mostly better now, but this was a catalyst for my abrupt career change.
I mention this because I think it's important framing: I'm not the type of person that would typically quit their secure, very-well-paid job as a staff engineer *during a pandemic* to pursue an unproven venture. But it felt urgent to me that I do this right now.
One of these numbers-in-circles is correctly centered. The other one *looks* correctly centered. 😅
Can you tell which is which?
Explanation in-thread 👇
With “true” mathematical centering, you get the result on the left. This is what happens by default in HTML/CSS. It centers the number according to an invisible box.
If we shift it a few pixels to the right, its stem aligns with the Y axis, and it looks ever-so-slightly nicer 💖
I wrote a blog post all about these sorts of small tweaks, “Chasing the Pixel-Perfect Dream“: joshwcomeau.com/css/pixel-perf…
It reminds me of a well-tended garden. Each plant that you prune has a negligible impact, but in aggregate, it makes a huge difference.
In Summer 2020, I was trying to figure out what I wanted to teach. Maybe Gatsby, since I worked for the org? Maybe React, since I had been using AND teaching it for years? Maybe whimsical animations, since that's my whole jam?
I picked… CSS.
Explanation in-thread 👇🏻
First, some brief context: In 2020, I developed an RSI that left me unable to type or use a mouse. It's mostly better now, but it was an eye-opening experience, and one that convinced me that it was time to do something I had wanted to do for years: focus exclusively on teaching.
For a few years I've been teaching part-time at a local coding bootcamp. It's super fulfilling work, because I can see the impact I have on students looking to start a new career.
Impact is important to me. I wanted to teach something that would meaningfully affect people!