When I took the TA position for COMP 2310 Theoretical Foundations of CS, I honestly thought it was going to be about explaining things I already understood. I was wrong. Teaching theory at the rigour required in a second-year course forced me to rebuild mental models I had only ever pattern-matched.
The Feynman trap
There is a well-known idea: if you cannot explain something simply, you do not understand it. I thought I understood mathematical induction. I had used it in proofs, got full marks. But the first time a student asked me "but why does the base case matter if the inductive step works for all n?" I realised I had been faking it.
"The first principle is that you must not fool yourself and you are the easiest person to fool." — Richard Feynman
That question cost me two hours of real thinking. The answer is obvious once you see it — without a base case you have proved something vacuously, a chain with no anchor. But building the explanation that actually changes how someone thinks is a different skill from solving the problem yourself.
How it changed the way I write code
After a semester of teaching proofs, I started reasoning about my code inductively. Where before I would write a recursive function and test it with a few cases, I now ask: does my base case handle the trivial input? Is my recursive step guaranteed to make progress toward termination? This is just loop invariant thinking, but I only truly got it after teaching proofs to other people.
Similarly, teaching set theory and relations made me a much better database designer. When you understand what a relation is in the mathematical sense, normalisation stops being a checklist and becomes an obvious consequence of what you are modelling.
The takeaway
If you get the chance to TA — take it. The gaps in your understanding only become visible when you have to be precise enough for someone else. Theory courses are worth the most time you can give them. Everything else, eventually, is just syntax.