Career Longevity

Abstract

Problem: How does someone survive 30+ years in the game industry when most people burn out within a decade?

Approach: Tim Cain reflects on his own career, identifying the key factors β€” both deliberate and accidental β€” that kept him going.

Findings: Longevity came from a combination of stubbornness, having no alternative skills, genuine passion, an engineering mindset that made games feel low-stakes compared to life-critical software, and a chronic tendency to underestimate how much interpersonal drama game development involves.

Key insight: Lasting in the game industry isn't about avoiding burnout β€” it's about loving the day-to-day craft enough that the drama, the bad reviews, and the difficult people don't outweigh the joy of making games.

Source: https://www.youtube.com/watch?v=qRAUcX8cRZQ

The Question

Tim regularly gets asked: "How did you last so long in the game industry?" β€” often from people who tried it for two, five, or ten years before tapping out. His answer: making games is hard, and there's no single reason he survived. It's the combination of several factors that kept him going.

The Five Reasons

Stubbornness

There were specific games Tim wanted to make, and he knew it would take years to reach a position where he could make them. He needed time to develop the skills, learn to manage people for the parts he couldn't do himself, and build the self-knowledge to distinguish between "things I'll never be good at," "things I can learn," and "things I've learned enough." That self-knowledge alone took a long time.

No Alternative Skills

Tim started programming at 16 and has never been paid for anything other than making games and programming. He went to college and grad school, but never held a retail job, office job, or anything outside the industry. He acknowledges the luck and entitlement in this, but notes it also means he's literally unqualified for anything else β€” he'd need the most basic training to do other work.

Passion

Games remain a deep passion. Tim plays them constantly and has filled notebooks with game ideas for years. He continues writing down ideas even though he knows he'll likely never make most of them β€” not for lack of opportunity, but because the process of making games has become increasingly involved: cross-disciplinary, massive pre-production, scheduling nightmares.

Engineering Mindset β€” "At Least No One Dies"

Tim learned programming as an engineering discipline at an actual engineering school, where computer science students were trained alongside electrical and chemical engineers. They were taught horror stories of engineering failures.

The one that stuck with him: medical software controlling a radiation therapy machine. A user noticed a typo in a previous field and used arrow keys to move back and correct it. The UI changed the displayed number, but the software didn't actually process the arrow key navigation β€” the corrected value went into the wrong field. A patient was exposed to a massive, dangerous dose of radiation.

The lesson covered every failure: the UI shouldn't have worked that way, all fields should have been validated, out-of-range values should have been flagged, and the machine itself should have had a physical blocker preventing excessive radiation output. Multiple layers of software and hardware failures.

When Tim decided to leave grad school for games, he thought: "I love making games, and at least no one's going to die if there's a bug." That lower-stakes framing made the career feel sustainable.

Underestimating the Drama

Tim admits he consistently underestimated β€” and continues to underestimate β€” the interpersonal drama in game development. As teams grow, so does complexity: extroverts vs. introverts (who often won't tell you which they are, or will tell you with an ulterior motive), employees who need constant steering vs. fire-and-forget types, and people who don't even know their own working style. None of this is taught in school.

Scheduling compounds the problem. There are always deadlines, quality bars, feature lists, and budgets β€” often non-negotiable. Tim pushes back against the "just say no to crunch" crowd: he doesn't know how to ship a product without committing to a feature set, and features always take longer to get right, make fun, debug, and optimize than anyone estimates.

His friend calls him "the eternal optimist who never learns." Every new project, he thinks: this time I'll get the schedule right, people will work harder, nothing will go wrong. It never works out that way. But that optimism is itself part of why he keeps going.

The Bun Boy Story

After Fallout shipped, some players couldn't install or play the game from CD. The team couldn't reproduce it β€” players even mailed in their discs, which worked fine at the office. They eventually figured out certain CD-ROM drive brands (Acer, Laser) had inconsistent read rates between the inner and outer parts of the disc.

One player, "Bun Boy" from San Diego, demanded someone drive down and personally install the game for him β€” as if that were a service included with a $50 purchase. Tim offered workarounds: copy the files manually, or mail in the disc for a replacement. Bun Boy refused everything, insisting the CDs were defective. Tim finally suggested: install it at a friend's house β€” if it works, we're right.

Two days of silence. Then Bun Boy reappeared on the forums asking gameplay questions about Junktown.

Reviews and Forums

Tim stopped frequenting forums because of needlessly negative and argumentative people. He also recalls reviews that were barely disguised complaints about the RPG genre itself β€” including one that opened with: "I don't normally review RPGs, but I'm stuck reviewing this one, so here we go."

Despite all of this, he never let it kill the joy. The day-to-day of making a game remained fun.

The Summary

In Tim's own words, his career longevity comes down to: stubbornness, not knowing how to do anything else, passion for games, wanting to make products that wouldn't hurt anyone if they had bugs, and perpetually underestimating the drama. Or, more succinctly: "I don't know any better."

References