Teaching

Background: Tim Cain as a Teacher

During his four and a half years as a graduate student at UC Irvine (late 1987 to mid-1991), Tim was a teaching assistant for multiple courses including programming languages, operating systems, and neural networks. He especially enjoyed TA-ing operating systems three times under Professor Steven Franklin — an 8 AM optional class that self-selected for motivated students.

For the neural networks course, Tim had never formally studied the subject. He deep-dived into the material ahead of the students and taught it so effectively that a fellow TA was shocked to learn Tim had no prior coursework in neural networks — he'd learned it all within six months.

Tim later returned to UCI to teach game development classes in 1999 and 2000, and has since spoken at conferences and run his YouTube channel.

Teaching Forces You to Truly Understand

The central lesson Tim draws from teaching is that explaining something to others forces you to deeply examine it. When you just do things in your work, you often don't think about why. But teaching requires you to:

• Go back and think through everything you did
• Collect and organize your knowledge
• Codify implicit processes into explicit explanations

This process repeatedly revealed to Tim how his own thinking about game development had evolved. He'd start answering a question and realize: "This is how I used to do it, but now I do it this way — because the old way caused problems I couldn't solve."

Preferences vs. What's Actually Better

Tim makes an important distinction between ways that are better and ways he prefers. Some approaches feel more comfortable or come more naturally, but aren't necessarily superior. When he recognizes this gap, he seeks out collaborators or leads who are strong where he's weak.

He uses his experience with The Outer Worlds as an example: the development process required him to play the game in ways he didn't personally enjoy — testing different player builds and playstyles. You have to separate how you like to develop from how you like to play, because you're making a game for many different types of players.

Pair Programming as Teaching

Tim connects teaching directly to pair programming — sitting down with another programmer to write, debug, or optimize code together. Having to explain your code to a knowledgeable peer forces you to confront fundamental questions:

• Why are you using this data structure?
• Why this sorting algorithm?
• Is this actually the best approach for this use case?

Sometimes you can justify your choices. Sometimes you realize mid-explanation that your approach isn't optimal, and you rewrite it — something you'd never have done without that external prompt.

Tim also notes a practical debugging trick: when you're stuck on a bug in a chunk of code, sometimes just rewriting it from scratch in a different way eliminates the bug entirely — often faster than hunting for the bug itself.

Parenting and the Limits of Knowledge

Though Tim doesn't have children, he's been told that parenting mirrors teaching in how quickly it reveals what you don't know. Children ask relentless questions about things you may only understand superficially, or not at all.

He relates this to his own childhood — constantly asking his mother questions until she'd point him to the family encyclopedia set: "Why don't you go look it up and then tell me?" Those mini research assignments kept him busy and taught him to find answers independently.

Own Your Failures

Tim's most emphatic point: be very afraid of someone who claims they've never been wrong. Nobody is always right. If someone can't tell you about a time they messed up — genuinely owning it, not deflecting blame — they're hiding something.

In both years teaching at UCI, students asked him to talk about his mistakes: bad code, failed designs, things he had to redo. Tim considers these excellent questions and has dedicated entire videos to lessons learned from failure.

His rule of thumb when evaluating someone: ask them how they messed up. If their answer doesn't include real ownership — "I did this, it was completely wrong, I had to fix it" — that person will eventually be confidently wrong about something important.

The underlying principle: you learn more from failure than success, but only if you pay attention to it. If you don't examine why you failed, you'll keep failing the same way.

References

• Tim Cain. YouTube video. https://www.youtube.com/watch?v=zCBEonAqs8k