DEV Community

Cover image for How to Actually Learn From Tech Conference Talks (Instead of Forgetting Them by Friday)
Spartan Rich
Spartan Rich

Posted on

How to Actually Learn From Tech Conference Talks (Instead of Forgetting Them by Friday)

I have a YouTube playlist called "talks to watch." It has 140 videos in it. I've watched maybe half, and if you asked me what I learned from them, I could give you decent answers for about six.

That ratio bugged me enough that I spent a few months changing how I watch tech talks. Most of what I tried didn't work. A few things did, and they're simple enough that I wish someone had told me earlier.

Why talks are so easy to forget

A conference talk is built to be enjoyable in the room. The speaker has 30 or 40 minutes, a few good jokes, one or two big ideas, and a lot of setup around them. You nod along, it all makes sense, and the sense of "I get it" fades by the next morning.

The other problem is how we watch them. I used to put talks on at 1.5x while eating lunch, or with a second tab open. That's fine for entertainment. It's a bad way to learn anything, and I was pretending it was the second thing.

Decide what the talk is for before you press play

This sounds fussy, but it changed the most. Before I start a talk now, I write one line in my notes: why am I watching this?

Sometimes the answer is "I'm about to pick a queue for a side project and someone recommended this talk on Kafka vs. RabbitMQ." That's a talk with a job. I watch it closely and I take notes.

Other times the answer is "it was trending and the title was fun." Those I watch for fun and don't feel bad about forgetting. Most of my 140-video playlist turned out to be the second kind, and admitting that freed up a lot of guilt.

Watch with a pen, not a keyboard

When I typed notes during talks, I ended up transcribing. Whole sentences, sometimes slide text copied word for word. It felt thorough and was useless later, because I'd recorded what the speaker said instead of what I thought about it.

Paper forces you to compress. I keep an index card next to me and allow myself three things per talk: the main claim, one example that made it click, and one question I still have. If the talk can't fill that card, it probably wasn't worth the hour.

For a talk like Rich Hickey's "Simple Made Easy" (Strange Loop, 2011), my card says roughly: "simple means one fold or braid, easy means near at hand; they aren't the same. Example: state tangled with time. Question: where does my current codebase confuse the two?" That last line is the one I actually used at work.

Pause at the slide that matters

Most talks have one slide everyone screenshots. A diagram, a code sample, a list of tradeoffs. When you hit it, pause the video and try to explain it out loud before the speaker does.

You'll often get it wrong. That's the point. The gap between what you guessed and what they say next is where the learning sits, and it's the part you'll remember a week later.

Write the summary the same day

Within a few hours of watching, I write a short summary in my notes app. Four or five sentences, in my own words, with no video open. If I can't do it without rewatching, I didn't understand the talk, and I'd rather know that now.

I also add the timestamp of the best five minutes. Rewatching a 45-minute talk is a chore. Rewatching minutes 18 to 23 takes no effort at all, and that's often enough to bring the whole thing back.

Come back to it, on a schedule

This is the step I skipped for years, and it's the one that matters most. A single pass, however careful, fades. The research on this goes back to Hermann Ebbinghaus in the 1880s, and the fix he pointed to is still the best one we have: review the material again after a gap, then again after a longer gap.

For talks, that means looking at my index card or summary a couple of days later, then a week later, then a few weeks after that. Each review takes a minute. By the third one the idea is mine.

If you like the mechanics of this, I wrote up how to implement the SM-2 spaced repetition algorithm in JavaScript. It's the same idea, turned into code.

Where I got lazy, and what I built

I'll be honest. The index cards worked, but I stopped keeping the review schedule after about a month. It's one more thing to track, and talks weren't the only thing piling up. There were podcast episodes, long blog posts, and a steady drip of short coding reels I'd saved and never opened again.

So I built Recl to do the boring parts for me. You save a YouTube video, a reel, a podcast or an article. It writes a summary, files it under a topic, and then brings the key points back over the following days and weeks using spaced repetition. I still watch the talk properly and I still write my one line about why I'm watching it. Recl handles the part where I'd otherwise forget to come back.

Recl feed showing saved videos and articles sorted by topic

It doesn't replace watching closely. If you half-watch a talk, a good summary of it will still slide off your brain. But it removed the excuse I kept using, which was that keeping up with reviews was too much admin.

A smaller playlist

The best change I made was deleting about 90 videos from "talks to watch." Some were outdated, some I'd never really wanted to see, and a few I'd already watched and forgotten. That last group was the embarrassing one.

What's left is a short list of talks with a reason attached to each. I watch one or two a week, with a card next to me, and I come back to them. My recall is far better than it was with 140 half-watched videos, and I spend less total time on it.

If you try one thing from this post, try the one line before you press play. It filters out half your playlist on its own.


I'm Spartan Rich, and I build Recl, an AI learning app that saves your videos, reels, podcasts and articles, summarizes them, and uses spaced repetition so you remember what you learned.

Top comments (0)