Why I Teach What I Learn

The teaching trap

Early in my robotics work, I could build systems that worked. I could debug when they broke. But I couldn’t explain what made them work. That gap — between doing and teaching — is where I lived.

Then IEEE asked if I’d teach a workshop.

Articulation forces clarity

I prepared slides on Arduino interrupts. I wrote example code. And then, in front of a room, a student asked:

“Why does the interrupt run faster than the main loop checking a pin?”

I froze. The answer seemed obvious to me — interrupts are prioritized, the CPU switches context, blah blah — but none of those words explained why that matters to a robot.

So I drew a timeline:

• Main loop checks pin: happens every time through the loop (maybe every 10ms)
• Interrupt fires: happens immediately when the pin changes (microseconds)

The student’s eyes lit up. That was the insight: immediacy. Not speed, immediacy.

Teaching that workshop forced me to realize I’d been conflating two ideas. Fixing that confusion in real time — articulating it to someone else — locked the understanding in a way building alone never could.

Why this matters for breadth

When you work across domains, this becomes crucial. Robotics teaches you to think in state machines. That same insight applies to poker systems, genomics pipelines, anything with state. But you only see the parallel if you’ve articulated it clearly enough to teach someone else.

Teaching isn’t just about generosity. It’s the highest-fidelity test of whether you actually understand something.

What I’ve learned from teaching

• Assumptions are invisible until you name them. Students ask the dumbest, most important questions.
• Analogies are knowledge. If you can’t analogize your domain to another, you don’t understand the essence yet.
• Patience is precision. Explaining something clearly takes longer than doing it, but the understanding you get is deeper.

I’ll keep teaching because it keeps me honest.