Learning in Action
15 passages from 4 posts
The brain learns by running a vivid simulation of the experience — not by being told about it. Hands-on is the most direct path. Watching someone work in real time is the next best, because your brain simulates what it observes. Everything else — lecture, documentation, reading — is a distant third. This is why live demos work, why pair programming was formative, and why the quality of learning scales with how vividly you can run the scenario.
"The first runs at the end of every ship. If the LLM has stated the same non-obvious fact about the project twice in the session — "migrations live in db/migrations/.sql", "this repo uses make install, not npm install"* — and that fact isn't in CLAUDE.md, you get a single structured prompt asking whether to persist it. Hard cap of three candidates per ship; silent if nothing qualifies."
"The reason both reflection axes matter is that the value of any workflow system compounds with use. The more you run it, the more it knows about your specific project. But that compounding only happens if there's an explicit mechanism for capturing what's learned. Without one, the system stays static and you accumulate frustration."
"I built it partly as an experiment, partly because I was curious what patterns an LLM would surface from months of stream-of-consciousness text. The answer: more than I expected. Your writing patterns are more legible to a language model than they are to you."
"My years teaching iOS development at Lighthouse Labs shaped how I thought about onboarding. The question I'd ask before every class — what's the one thing I want them to be able to do by the end of this? — turned out to be a good frame for ramping up a new hire. Context doesn't transfer by osmosis. You have to design for it."
"I spent about two and a half years teaching iOS development at Lighthouse Labs — career changers making the jump into tech, most of them in their late twenties and thirties, most of them nervous. Before every class, I'd sit down with a blank doc and ask myself the same question: what's the one thing I want them to be able to do by the end of this?"
"That constraint shaped everything. If I couldn't build a live demo around it — something I could code from scratch in front of them, something they could follow in real time and reproduce themselves — I didn't have a lesson yet. I had an outline. The demo was the lesson. The rest was scaffolding."
"Part of why this works: people absorb concepts best when they arrive at the moment they're needed. A term without context is a weak memory pointer. The live demo forces the right sequence — the idea lands while you're already reaching for it."
"What you absorb from sitting next to a senior engineer — watching them think, watching them get stuck, watching them backtrack and try a different angle — is not something you can get from documentation or a blog post. It's the hesitations that matter. The moment where they pause before naming a variable. The way they open a file they haven't touched in six months and navigate it without getting lost. The reflex that says "this is getting complicated, let me step back.""
"None of that gets explained. It transfers by proximity."
"The live demo was my version of the same thing: get out of the way of the content and let them watch the process. Not the polished output — the process. The typing, the mistakes, the backspace, the "oh wait, let me try this instead.""
"What I didn't realize at the time was that the constraint wasn't just good pedagogy. It was a mirror. The format I kept returning to — live demo, hands-on, in the moment — was the format that worked because it was the format that worked for me. I was teaching the way I would have wanted to be taught."
"Hands-on, in-action learning is my style. Recognizing your own learning style is step one. Step two is accepting that it's not the style. It's a style."
"Some people need to read before they can do. Give them a live demo first and they're lost — they needed the mental map before the territory made sense. Some people need to write it down before it sticks, to explain it back before they own it. Some people learn by failing in private and then asking a very precise question. Some people are watching the demo but not tracking the code at all — they're watching how you handle being wrong in front of an audience, and that's what they'll remember."
"Caring about people shows up most clearly in whether you bother to understand how they learn — not just whether you explained the thing correctly."
"Teaching changed how I lead. When I'm onboarding an engineer or working through a hard technical problem with someone, I'm still asking the same question I asked before every class: what's the one thing I want them to be able to do? And I'm still watching for the difference between someone who's nodding and someone who's actually there."