Abstract
Problem: Why do some game developers — and software engineers in general — fail to regularly use their own products, and what are the consequences?
Approach: Tim Cain draws on decades of industry experience to identify the five main reasons developers don't play their own games, evaluating each critically.
Findings: The reasons range from understandable (burnout, no allocated time) to problematic (apathy, loss of perspective). Cain argues none are sufficient excuses and that regularly using your own product — before and after launch — leads to better patches, better sequels, and better craft.
Key insight: If you make something, take pride in it and use it. You will always find things to fix — and that awareness improves both the current product and your future work.
What "Eating Your Own Dog Food" Means
The phrase refers to a simple principle: if you make a product, you should use it yourself. In game development, this means playing your own game — not just during development, but after it ships. Tim Cain distinguishes this from his earlier video about developers playing games in general; this is specifically about playing your game.
Playing after launch serves two purposes: it reveals what remained unpolished or broken (guiding patch priorities beyond just player-reported issues), and it informs future projects by highlighting which design pillars weren't nailed.
The Shipped Build Problem
Cain shares that he has worked on at least two games where the publisher shipped an earlier build than the one the team had ready. He was literally holding a CD with a more recent build that fixed bugs — in some cases egregious bugs visible in the opening cinematic — but the publisher insisted on shipping the older version to meet a deadline. Playing after launch doesn't mean the developer wanted those bugs to exist; it means they can still learn from the final product.
Five Reasons Developers Don't Play Their Own Games
They Don't Play Games at All
Some people in the industry treat it purely as a 9-to-5 job. They come in, do their assigned features, and go home without thinking about work. Cain references his "jobs, careers, or callings" framework — all three types have a place on a team, and a mixed team is stronger than a homogeneous one. The only thing that should be homogeneous is the shared vision of what game you're making.
They Don't Have Time
During crunch culture, developers were given a full day's work and any game-playing was extra hours. Now that work-life balance is more respected, the problem persists differently: leads and producers assume developers will play the game, but never actually allocate time for it. A developer given a day to implement a feature will spend an hour or two verifying that specific feature works — jumping directly to where it appears, checking the UI, animation, and frame rate — but they won't play from the beginning like an actual player would.
They're Burned Out
Exhaustion makes even clicking the "play" button feel impossible. When you're burned out, what you need is to not look at the screen for 15 minutes, not to spend your downtime doing more of the same work. Cain treats this as understandable but still a problem for the product.
They're Too Close to the Game
After working on a game for years, developers stop seeing the issues. Bad animations, frame rate stuttering, useless perks — they've either reported these things and mentally moved on (assuming they'll get fixed), or they've genuinely become blind to them. This is one reason fresh QA hires are valuable: after a few months, even dedicated QA testers lose their ability to spot problems they see every day.
Knowing How the Sausage Is Made
This is distinct from being too close. Here, the developer sees too clearly. What a first-time player would experience as amazing reactivity, the developer knows is a narrow set of triggers on specific variables, fired infrequently enough to feel organic. They see the shortcuts, the half-measures, the rickety scaffolding. The magic is gone. When this happens to the people in charge, they often start wanting to overhaul existing content or create new content out of boredom — even though the player buying the game has never seen any of it before.
Cain's Own Practice
Cain has played every game he shipped, both before and after launch, at every company where he was present for the ship date. On some teams, nobody played the game more than he did except QA (whose literal job is to play all day). He did at least 16 full playthroughs of The Outer Worlds — eight of which he documented in detail in a separate video.
Beyond Games: A Universal Problem
The "not eating your own dog food" problem extends far beyond gaming. Cain describes frustrations with video processing software, word processors, consoles, and especially music streaming apps. He devoted an entire video to redesigning a music streaming app's UX because of how frustrating every modern one is to use.
A specific example: returning to old playlists with hundreds of songs to discover that half a dozen or more are now broken links. The musician remastered a song, the old version was deleted, and the streaming service never re-linked the playlist entry. There's no notification, no option to auto-update to the new version — just silent broken links buried in a long list that you only discover by manually scrolling through.
The Bottom Line
The difference between briefly testing your product and truly living with it — for years or even decades — is enormous. Looking back at Fallout, Arcanum, and Temple of Elemental Evil, Cain sees things he wouldn't do today that he didn't notice at the time. The lesson is simple: if you make something, take some pride in it and use it. There are probably things you can fix.
References
- Tim Cain. YouTube video. https://www.youtube.com/watch?v=-xjJw145Qpc