What Teaching 200 Students Taught Me About Explaining Complex Ideas

My TA appointment for CS3000 ends this week. Over 200 students, one semester, more office hours than I can count. I came into this thinking I'd be helping students with pandas syntax and debugging Jupyter notebooks. I'm leaving with a fundamentally different understanding of what it means to explain things well.

The Gradient Descent Moment

Three weeks into the semester, we covered gradient descent. I explained it the way I learned it: partial derivatives, loss surfaces, learning rates, the math. I thought it was a clean explanation. Clear, correct, complete.

A student came to office hours afterward. She'd been staring at her notes and couldn't connect the math to what was actually happening. "I understand the formula," she said. "I just don't understand why it works."

So I tried again. I asked her to imagine standing on a foggy hillside and trying to find the lowest point. You can't see the whole landscape, but you can feel which direction slopes downward under your feet. You take a step that way. Then you feel again. Step again. That's gradient descent. The math just formalizes "feel which way is down" and "take a step."

Her face changed. She got it. Not because the second explanation was more rigorous, but because it connected an abstract concept to something physical. That was the first time I really understood the difference between being correct and being understood. They're not the same thing, and in teaching, only one of them matters.

Office Hours at 8 PM

The scheduled office hours for CS3000 were twice a week. By mid-semester, I was holding unofficial sessions almost every evening. Not because I had to, but because that's when the real teaching happened.

There was a student, an economics major taking the course as an elective, who came to almost every session. He was struggling with the programming components. Not because he wasn't smart, but because he'd never written code before and the class moved fast. One evening in October, he was trying to merge two DataFrames and kept getting duplicate columns. We sat together for 45 minutes, walking through what a merge actually does, drawing little tables on scratch paper, running the code line by line.

When it finally clicked, he said, "Oh, it's just like a VLOOKUP in Excel." And he was right. That was exactly the right mental model for him. I never would have reached for that analogy on my own because I don't think in Excel. He taught me that the best explanations meet people where they already are, not where you think they should be.

The Art of Simplification

There's a quote attributed to Einstein, something about not being able to explain things simply meaning you don't understand them well enough. I used to think that was a nice platitude. After this semester, I think it's literally true.

Every time I struggled to explain a concept, it was because my own understanding had gaps. I could execute the code, get the right answer, pass the test. But when a student asked "but why?" and I couldn't answer without falling back on jargon, that was a signal. Not about them. About me.

Teaching 200 students forced me to rebuild my understanding of topics I thought I'd mastered. Regularization isn't just "adding a penalty term." It's asking "what if we told the model it's not allowed to rely too heavily on any single feature?" Cross-validation isn't just "splitting data K ways." It's asking "how do we know our model's performance isn't just luck based on which data it happened to train on?"

These reframings made me better at the material. Not just better at explaining it, but better at understanding it. Teaching and learning turned out to be the same process, viewed from different angles.

What I Didn't Expect

I didn't expect to care this much. About students' grades, about their understanding, about whether they felt comfortable asking questions. I didn't expect to feel a genuine sense of pride when a student who struggled all semester pulled off a strong final project. I didn't expect that the most valuable skill I'd develop this year wouldn't be technical at all.

Technical communication is the most underrated skill in engineering. The ability to take a complex idea and make it accessible, without dumbing it down, is worth more than most technical skills on a resume. Every great engineer I've worked with, at Myelin, at hackathons, in my courses, has been someone who could explain their work clearly. It's not a coincidence.

Moving On

I'm wrapping up at Northeastern soon. The TA role was supposed to be a way to fund my degree and stay close to the material. It turned into something bigger than that. It made me more patient, more precise in my communication, and more aware of the gap between knowing something and being able to share it.

To my 200-plus students: thank you for every question, especially the ones that stumped me. You made me better at this.