Mentoring

Tim's Early Career: No Mentors Available

Tim started at Pegasus Software (later Cybron) at age 16 in 1981. Despite being the youngest person there, no one could mentor him — the game industry was so new that even the people in their 30s and 40s had never made a game before. Everyone was figuring things out together.

Tim had been self-teaching since age 12-13, and by 16 he was actually teaching the lead programmer fundamental concepts like linked lists, recursion, and stack management. He found himself in the paradoxical position of being the youngest but most technically knowledgeable person on the team.

Still Wanting a Mentor at 20+ Years Experience

By the time Fallout shipped, Tim was 32 with over 15 years in the industry. At Troika in his mid-30s, he had two decades of experience — sometimes 10x more than colleagues who had entered the industry just a year or two prior, including publishers telling him "how things are."

Yet he still wanted a mentor. He knew what he didn't know: group management, contract negotiation, networking with other industry professionals, source control practices, build systems, and other operational knowledge that no one taught and some employers actively discouraged sharing (especially networking, since companies feared employees would discover better opportunities elsewhere).

People Who Refuse Advice

Tim identifies a frustrating pattern: people who reject all mentoring, insist they know better, then blame others when things go wrong. He shares a specific story of someone on one of his own projects who argued they had a better approach, convinced Tim to try it, and months later the result was worse — costing time, money, and shipping features in a bad state.

The most exasperating version: people who refuse advice, fail, and then say "you should have told me not to do this" — when that's exactly what was done.

Learning From Failure — Preferably Someone Else's

Tim pushes back on the common industry wisdom that "people just need to learn from their own failures":

• Failure on someone else's dime is a problem. If you're a solo indie developer, learn from your own mistakes all you want. But on a team project, your insistence on ignoring warnings costs other people's time and money.
• You can learn from other people's failures. Read postmortems (Game Developer Magazine used to publish many). Read between the lines — look past the generic "we over-scoped" admissions to find the real lessons: a toxic team member not removed early enough, a manager's ego driving bad design decisions.

How to View Mentors

Don't think of mentors as people saying "I'm right, shut up and do it." Think of them as people saying "I've failed in the area you're working in — learn from my failures." If someone tells you there's a pothole ahead, don't speed up thinking you're a good driver. Switch lanes.

Why Tim Turns Down All Mentoring Requests

Tim receives more mentoring requests than any other type of communication — ranging from "read my design doc" to "play my game" to "read my book" to even "read my movie script." He turns them all down.

His YouTube channel is his mentoring. It reaches far more people than one-on-one sessions ever could — with 165,000 subscribers and viewership roughly double that number. His goal is to share his point of view on game development so viewers can either adopt it or develop their own informed perspective.

The best part, as Tim sees it: you don't have to listen. You don't have to agree. But if even some of what he says makes you think "huh, I didn't consider that," then the mentoring is working.

References

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