My Work Pattern For Programming

tim-cain programming productivity work-patterns game-development

Abstract

Problem: What daily work pattern produces the best programming output, and how should a developer structure their day around deep coding work?

Approach: Tim Cain shares decades of personal experience from Interplay, Troika, and Obsidian, including a concrete debugging technique that proved how damaging interruptions are to code quality.

Findings: Programming is uniquely sensitive to interruption compared to other game development tasks. Protecting your peak hours for uninterrupted coding, starting each day with a simple task, and pushing meetings/design work to off-peak hours dramatically improves productivity and code quality.

Key insight: Always save one easy coding task for tomorrow morning — it eases you back into the programming mindset and lets you ramp up to harder problems naturally.

The ZZZ Trick: Proof That Interruptions Kill Code Quality

Tim developed a simple but revealing habit early in his career: whenever he got interrupted while coding, he'd type // zzz as a comment to mark the spot. He started this on Rags to Riches at Interplay, where he worked in cubicles and shared offices for years (he didn't get his own office until the last year and a half of Fallout development).

The results were stark: nine times out of ten, when a bug report came in, the error was within a few lines of a zzz marker. He could have pages of code without any zzz comments — the bugs clustered around interruption points. This convinced him that protecting coding time from interruptions was essential.

Programming vs. Design Work

Interestingly, Tim tried the zzz trick on design work too — writing system mechanics, lore, and dialogue — and found no correlation between interruption markers and design flaws. Design problems came from inherent system issues, bad interactions between systems, or balance problems (Tim admits he was "never good at getting numbers right"). This meant interruption protection was specifically critical for programming, not all tasks equally.

Structure Your Day Around Your Peak

Tim codes during his most productive period — for him, that's early morning. He wakes at 5–6 AM (a habit forced on him ~23 years ago by a rescue German Shepherd named Cooter who demanded a sunrise "perimeter check" of the yard every morning).

Why Mornings Work

  • Offices are emptier — far fewer interruptions before 9–10 AM
  • Nobody notices early arrivals — "People view you as a hero if you stay late. No one cares or notices if you come in early."
  • Even at home, the house and neighborhood are quieter in the morning

The Daily Rhythm

  1. 5–7 AM: Arrive / start work. Code for 2–3 uninterrupted hours with ambient music (Brian Eno, Harold Budd, Aphex Twin's Selected Ambient Works — anything without vocals, preferably long tracks like Eno's Thursday Afternoon and Neroli, each a single 40-minute piece)
  2. ~9–10 AM: Take a real break — walk around, check in on team members, walk the dog, get coffee (he fondly recalls Obsidian's cold brew machine as "mana from heaven")
  3. Late morning / afternoon: Meetings, production work, design work, publisher calls — everything that tolerates interruption

Tim emphasizes that "taking a break" means physically moving, not just standing up. Walking the dog, visiting colleagues, getting a drink.

The Easy Task Trick

Tim's most emphatic piece of advice, practiced for 30+ years:

Always save one simple, easy-to-code task as the first thing you'll do tomorrow morning.

When he encounters an easy task while coding during the day, he deliberately skips it. At the end of his coding session, when writing his notes, the very first item on his to-do list is that easy task.

Why It Works

When you arrive in the morning, your mind is a blank slate — "What did I do yesterday? I did a bunch of things, I don't really remember." Having that simple task waiting means you can immediately open your IDE, start coding something straightforward, and within 30 minutes to an hour you've reconnected with the codebase. By the time the easy task is done, "all my code part of my brain is active" and you can jump into progressively harder problems.

Without this ramp-up, Tim says he simply can't "switch on and go — okay, I'm coding now."

Summary

Tim's programming work pattern in four rules:

  1. Code during your peak hours — morning for him, but evening works too; find your rhythm
  2. Protect that time from interruptions — no meetings, no check-ins
  3. Start each day with an easy task to ramp back into the coding mindset
  4. Push everything else later — meetings, design, production, all go to off-peak hours

The advice is adaptable: if you're an evening person, flip the schedule. The key is identifying your rhythm, establishing it early, and defending it wherever you work.

Source: My Work Pattern For Programming — Tim Cain (YouTube)

References