About My Notes, Part 2

tim-cain fallout game-development notes blame credits companions management storytelling

Abstract

Problem: Why do viewers interpret Tim Cain's development stories as grudge-holding or blame-assigning, when that's not his intent?

Approach: Tim explains how his detailed note-taking system works, why it sometimes misleads even him, and uses the Fallout companions story as a case study in the difficulty of assigning blame.

Findings: Even when facts are completely uncontested, different people will assign blame to different parties depending on their interpretive lens. The goal of sharing these stories isn't to blame anyone — it's to normalize that bad situations happen and encourage doing better next time.

Key insight: Notes are tools for accuracy, not ammunition — and even perfectly factual accounts will be interpreted through the listener's own biases about who deserves blame.

Source: https://www.youtube.com/watch?v=xTF-XJU135I

1. Why People Think He's Holding Grudges

Tim addresses a recurring type of comment on his channel: viewers who assume that because he tells detailed stories involving people doing "not nice things," he must be angry or holding grudges. He pushes back on this firmly — he doesn't see any point in staying angry.

The illusion of grudge-holding comes from the detail itself. Because his notes are so thorough, when he retells a story it sounds like something he's been stewing over for years. In reality, he reviews his notes before filming, sometimes copy-pasting relevant entries onto a reference sheet. The notes are his long-term memory, not an emotional ledger.

2. How Notes Serve (and Sometimes Mislead) Him

2.1. Notes as External Memory

Tim openly acknowledges he forgets things and sometimes conflates events. His notes correct for this. He has entries about events he doesn't even remember — he's contacted people who confirmed "yes, that happened" when he had no recollection beyond what was written down.

2.2. When Others Deny the Record

Several times, people have denied that events occurred or that they said certain things. Tim notes that in some cases he has the person's own email as part of his records. Some people still double down: "I don't think that ever happened." This is simply what happens when you work for decades — memories diverge, and written records become essential.

2.3. Correlation vs. Causation

A colleague once contacted Tim after a video to point out that he had taken two correlated events from his notes and presented them as causation (A caused B, when really it was just A and B happening near each other). Tim acknowledges this as a real pitfall — notes record what happened, not necessarily why.

3. Notes as a Management Tool

One of the biggest benefits: notes let Tim notice patterns in people he works with. He describes himself as somewhat naive — someone can fool him once, and a month later he's ready to be fooled the same way. Notes help him catch recurring behaviors he'd otherwise miss.

3.2. Tailoring Management Style

As programming director, he kept notes like "this person wants you to stop by every day" and "this person doesn't want to see you until the final day." When managing teams of 30, 50, or 100 people, these notes were essential reminders for individualized management.

3.3. Performance Reviews

Notes with specific examples made reviews more meaningful. Whether praising accomplishments or identifying areas for improvement, people want concrete examples — not vague generalities.

4. The Fallout Companions Case Study

Tim uses the Fallout companions saga to illustrate how even uncontested facts lead to wildly different blame assignments.

4.1. The Sequence of Events

  1. Early decision: The team decided to cut companions from Fallout. A major reason was the "choice and consequence" pillar — companions who act independently could undermine player agency (e.g., a companion starts combat you didn't want, and you face the consequences).

  2. Late addition: With less than a year left (possibly 6-8 months), two team members found an ingenious way to add companions via scripts. They started with Dogmeat — no dialogue, no inventory. QA loved it. Tim loved it too.

  3. The bugs: This caused UI and AI bugs because Tim's code (he wrote both systems) was never designed to handle companions. This is why trading with companions uses the steal UI, and why Ian shoots you in the back during burst fire — there was no friendly-fire cone check because companions weren't supposed to exist.

  4. No time to fix: Tim was already working 12-14 hour days, six to seven days a week. There was simply no capacity to properly integrate companion support.

4.2. Who Gets the Blame?

Tim lays out how different people assign blame differently from the exact same facts:

  • "Blame the lead designer" — for cutting companions in the first place, since they turned out great
  • "Blame the two scripters" — for pushing a feature in too late, causing bugs
  • "Blame the producer (Tim)" — for not shutting down the late addition
  • "Blame the programmer (also Tim)" — his code shipped with the bugs, full stop

Each interpretation uses a different lens (top-down responsibility, proximate cause, strict accountability), and each is defensible. That's the point.

5. The Real Reason He Tells These Stories

Tim's purpose in sharing development stories is not to assign blame or settle scores. It's two things:

  1. You're not alone. These situations happen on every multi-person project, not just in games. If it hasn't happened to you yet, it will.

  2. It's not the end of the world. Accept the consequences, then figure out how to do better next time. If you were at fault, fix your behavior. If someone else was, put process guardrails in place. If blame is ambiguous, establish rules like "no new features in the last 6 months."

The worst response is pretending bad things don't happen and that you're never at fault. Acknowledging problems, learning from them, and improving — that's the whole point. And that's why he's glad he kept all those notes.

6. References