I started teaching computer science as a graduate assistant and never fully stopped. Even now, I lecture part-time at Notre Dame University in Lebanon. And the surprising thing is that teaching made me a better engineer, not the other way around.
When you stand in front of 40 students and try to explain recursion, you cannot hide behind jargon. You cannot wave your hands and say it is a well-known pattern. You have to actually understand it deeply enough to explain it simply. And that pressure - to make the complex accessible - rewires how you think about everything.
The first thing that changed was my naming. Before teaching, I would write variables like 'idx' and 'tmp' and 'res' because I knew what they meant. After watching students struggle with my code examples, I realized that clear naming is not about being verbose. It is about being unambiguous. 'currentStudentIndex' is not longer than 'idx'. It is clearer. And clarity compounds across a codebase.
The second thing was my abstractions. Students would ask why I split a function into three smaller ones. Is it not simpler to have everything in one place? And I had to articulate the real reason - not because it looks cleaner, but because each function should answer exactly one question. When you debug, you want to know where to look. When you test, you want to know what to test. Single-responsibility is not an aesthetic choice. It is a navigation tool.
Teaching also killed my tolerance for clever code. I used to enjoy writing compact one-liners and chained functional expressions. Then I put one on a slide and watched 40 pairs of eyes glaze over. Now my rule is: if a junior developer would need to pause and re-read a line, it is too clever. Readable code is not dumbed-down code. It is code that respects the reader's time.
The biggest lesson was about the why. Students do not just want to know how to implement a binary search tree. They want to know when they would use one instead of a hash map. The why gives the how its meaning. I started writing more comments that explain why a decision was made, not what the code does. The code tells you what it does. The comment should tell you why this approach was chosen over the alternatives.
I bring this teaching mindset into code reviews now. When I leave feedback, I try to explain the principle, not just the fix. Not 'use a Map here instead of an object' but 'Maps handle frequent insertions and deletions better because they are optimized for that access pattern, and this function is called in a hot loop.' The extra sentence turns a correction into a lesson.
If you ever get the chance to teach, take it. Tutoring, mentoring, giving internal talks, writing documentation. The act of explaining is the most underrated skill in software engineering. It forces clarity. And clarity is the foundation of everything that works.