I thought I knew the material
Then someone asked the simplest possible question — 'why do we need pull-up resistors?' — and I realised I had a textbook answer and not an actual explanation. That moment was the start of teaching being the most useful thing I have done for my own engineering.
You cannot bluff a curious student. They will keep asking 'but why?' until you either reach the bottom of your understanding or admit you do not know. Both are useful outcomes. Both are humbling the first few times.
Different audiences expose different gaps
I have run sessions for first-years who had never seen a breadboard and for final-years who had built quadcopters. The exact same material lands differently. The first-years need analogies and patience; the final-years need precision and challenge. Adapting the same lesson for both audiences forced me to understand the material at multiple levels of abstraction.
That skill — switching between deep technical detail and the one-sentence summary on demand — is the single most underrated career skill I have picked up. It shows up in interviews, in design reviews, in writing, in this blog. Teaching trained it without me realising what was being trained.
Debugging as curriculum
Most courses teach the happy path: here is how a UART works, here is how to write to it, here is the expected output. Real embedded work is the unhappy path. So I started building broken hardware into my sessions on purpose — a misconnected wire here, a wrong baud rate there — and let students debug their way out.
It changed everything. Students who had been waiting to be told the next step started forming hypotheses on their own. They learned to read a logic analyzer trace, to suspect their wiring before their code, to think like an engineer instead of a recipe-follower.
Now I use the same approach on myself. Whenever I onboard onto a new board, I deliberately break something and recover from it. The exercise teaches me the system faster than any datasheet ever does.
Teaching made me a better writer
Most of the clarity in my code reviews, project READMEs, and even this blog comes from years of having to explain things on a whiteboard with five minutes left in a session. You learn to drop the jargon, lead with the intuition, then layer in the precision once the intuition has landed.
If you ever get the chance to teach something, take it. The slowest learner in the room will sharpen you faster than the smartest collaborator.
What I tell new mentors
Three things. First, prepare the demo before the lecture — if the live code does not run, the lesson is over. Second, ask more questions than you answer; the student who explains it back to you remembers it forever. Third, share your own bugs. The day I started telling students about the time I shorted my own dev board, they started telling me about theirs, and our debugging sessions got dramatically faster.
Teaching is not a side activity if you are serious about engineering. It is the same activity, with a tighter feedback loop.