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?

Not understand. Do.

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.

The Thing You Absorb by Watching

Before Lighthouse, I’d been a senior engineer at Pivotal Labs. Pivotal is where I first encountered pair programming as a serious practice: not a team exercise or a code review substitute, but the primary unit of how work got done. One computer, two keyboards and mice, so each engineer can take over and drive. The true co-pilot experience.

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.”

That’s My Style. Not Everyone’s.

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 Through How You Teach

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.