I spent four rounds as a programming instructor before I ever had a real engineering title. That order matters more than I realized at the time.
Between 2018 and 2021, I taught Python, Java, and Arduino at a government virtual academy in Abu Dhabi. I was young. Most of my students were younger. Each cohort was different, but the lesson was always the same: if you can't explain it, you don't know it.
The explanation test
There's a specific moment in teaching where you realize your understanding has a hole. It usually happens when a student asks "why?" about something you've been doing automatically for years. Why does the loop start at zero? Why do we use a function here instead of just writing the code inline? Why is this way better?
"Better" is a dangerous word in programming because it implies a comparison, and comparisons require context. Better for whom? Better by what measure? Better now or better in six months? Teaching forces you to confront these questions in real time, with someone watching your face while you figure out if you actually have an answer or if you've just been repeating a pattern.
That confrontation is priceless. It's what separates someone who can code from someone who can think about code.
Patience as a technical skill
The other thing teaching gave me, and I didn't appreciate this until much later, is patience. Not the passive kind. The active kind where you watch someone struggle with a concept and resist the urge to grab the keyboard and do it for them.
That restraint translates directly to leadership. When I'm working with my team now, the hardest part of my job isn't solving the problem, it's creating the space for someone else to solve it. Giving enough direction to unblock them without so much that they stop thinking independently.
Teaching taught me that the goal isn't to demonstrate your own competence. The goal is to create competence in someone else. And that's a fundamentally different kind of problem-solving.
The feedback loop
One thing people don't talk about with teaching: it's one of the fastest feedback loops in existence. You explain something, you see in real time whether it landed. The blank stare. The slow nod. The sudden light in someone's eyes when a concept clicks. You calibrate, adjust, try again.
In software engineering, feedback loops are often long and mediated by systems. You write code, deploy it, wait for metrics, interpret dashboards, have a meeting about the dashboards. Teaching is direct. Human-to-human. You say a thing and immediately know if it worked.
I think that's why I gravitate toward building tools for people I know, internal systems where I can watch someone use what I built and see exactly where they pause, where they smile, where they get confused. It's teaching energy applied to engineering. Build, watch, adjust.
The order mattered
If I had gone straight from university into a pure engineering role, I think I'd be a different kind of builder. Probably more technically deep in some areas. Probably worse at everything that involves another human being looking at what I made and needing to understand it.
Teaching first meant that by the time I started building real systems, I already thought about the person on the other end. Not the "user" in the abstract UX sense. The actual person. With their specific confusion and their specific goals and their specific way of describing what they need in language that never quite matches the technical reality.
That gap between what people say and what they mean is where most bad software gets built. Teaching trains you to hear across that gap.