Before I was a software engineer, I was a STEM tutor. From 2015 to 2019 at Clark College, I tutored every math class from elementary algebra through Calculus IV, differential equations, and linear algebra. Every computer science class. Every electrical engineering class. Physics. Some chemistry.
And then things got fuzzy. I started tutoring classes I hadn't taken — business law, nursing, mechanical engineering. I didn't know the material, but I found that the skill wasn't knowing the answer. It was knowing how to get there with someone.
That instinct has shaped everything about how I work as an engineer.
The Student Who Changed How I Teach
There's a student I'll never forget. He was an older guy with a welding background. He knew some fractions from his trade — halves, quarters, three-eighths — but he didn't believe that one-seventh was a real fraction. He was frustrated, aggressive about it, and the tutoring center was busy.
Instead of explaining why he was wrong, I tried something different. I told him that if we look at something as if we hate it, we're not going to want to do it, and we're not going to do well with it. I asked him for an example of something he liked — something he was good at because he liked it. He gave me a blunt answer that turned a few heads in the tutoring center. But the point landed: he was good at things he enjoyed because he engaged with them.
We did some fraction work and it started clicking. He told me to give him something harder. So instead of addition and subtraction, I gave him multiplication — which he found easier and started getting excited about. Our time ran out, but as he was leaving, he told the front desk staff that I needed a raise.
That moment taught me something I still carry: the first job isn't teaching the material. It's changing the relationship with the material. If someone has decided they can't do something, no amount of explanation will help until you address that belief first.
Meeting People Where They Are
One of the first things I learned as a tutor is that everyone learns differently. Some students need to hear an explanation. Others need to see it drawn out. Some need to work through it with their hands. And a lot of students don't actually know which type they are — so part of the job is figuring that out quickly.
I do the same thing when working with junior engineers. When someone comes to me stuck on a CORS error, a unit test that won't pass, or a Terraform configuration they can't get right, the first thing I do is figure out how they learn. If they're auditory, I explain it. If they're visual, I draw it. Once they seem to understand, I have them explain it back to me or give me an example — because being able to explain something is the real test of understanding.
This isn't something I learned in engineering. I learned it sitting across from a nursing student trying to understand pharmacology dosage calculations, or a business law student working through contract analysis. The domain changes. The skill doesn't.
The Socratic Method in Code Review
The reason I could tutor classes I'd never taken is the Socratic method. Instead of giving answers, I'd ask questions and learn alongside the student. “What do we know so far? What does this term mean? What would happen if we tried this?” It forces the student to build their own understanding rather than borrowing mine.
I use the same approach in engineering, especially during code review and mentoring. Instead of saying “this won't work because of X,” I'll ask “what happens when this gets called concurrently?” or “what does this return when the input is null?” The engineer arrives at the issue themselves, which means they'll recognize the pattern next time without me.
It's slower in the moment. But it scales. A junior who learns to ask themselves those questions doesn't need me to ask them forever.
Debugging Mental Models
Here's the connection I didn't expect: debugging a student's understanding and debugging a distributed system use the same core skill. In both cases, you're building a mental model of something you can't directly observe.
When a student gets the wrong answer, the interesting question isn't “what's wrong?” — it's “where did their reasoning diverge from reality?” Maybe they understand the concept but misapplied a rule. Maybe they have a fundamental misconception that's been silently producing wrong answers for weeks.
Production bugs work the same way. The stack trace tells you what went wrong, but the real work is figuring outwhere the system's behavior diverged from what you expected. Is it a bad assumption in the code? A race condition that only appears under load? A silent failure that's been compounding for months?
In both cases, you're not just fixing the immediate problem. You're finding the gap in the mental model — yours, the student's, or the system's — and correcting it at the source.
What Engineering Taught Me About Teaching
The “vice versa” in the title is real. Engineering has changed how I'd approach tutoring if I went back to it.
Engineering taught me to think in systems. When a student is struggling, I used to focus on the immediate problem — this equation, this concept, this assignment. Now I'd think about the system: What prerequisite knowledge is shaky? What's their study process? Are they struggling with the material or with how they're approaching the material?
It also taught me to value feedback loops. In engineering, you write tests to catch regressions. In tutoring, having a student explain something back to you is the test. Both are about verifying that your mental model matches reality before moving forward.
The Thread That Connects It All
If I'm honest, the through-line of my career isn't a technology or a domain. It's this: I care about helping people understand things. Whether that's a student who doesn't believe in fractions, a junior engineer debugging their first CORS error, or a group of engineers in a Discord server on a Friday night going deep on how Kafka works.
The tools change. The skill is the same: figure out where someone is, meet them there, and help them get to where they need to be.