Software Engineering Daily — “Running Doom in TypeScript with Dimitri Mitropoulos”
Episode Date: November 25, 2025
Host: Josh Goldberg
Guest: Dimitri Mitropoulos (Developer at Vercel, Founder of Michigan TypeScript)
Episode Overview
This episode dives into one of the most unique side projects in software engineering: porting the classic game Doom to run entirely within the TypeScript type system. Host Josh Goldberg sits down with Dimitri Mitropoulos, the creator of this mind-bending project, to discuss the technical journey, its unanticipated lessons, TypeScript type-level programming, and sustainability of advanced software engineering side projects. The episode also explores Dimitri’s career trajectory from linguistics and speech pathology into software and the broader impacts of such unconventional pursuits.
Key Discussion Points & Insights
Dimitri’s Unusual Path to Software Engineering
- Origins in Tech: Programming since childhood, Dimitri was inspired by early web experiments and watching his mom use spreadsheets.
- “I had my first email address when I was 6... And I saw her writing formulas and it was so interesting to me... that was like the first exposure that I had to software engineering.” (01:47)
- Academic Background: Studied Latin, linguistics, and speech pathology; never formally set out to be a software engineer.
- “I have three bachelor’s degrees and a master’s degree, none in software engineering. I didn’t think of myself as a software engineer at the time...” (05:30)
- First Professional Experience: Out of necessity, switched to software—started with Visual Basic and COBOL out of economic need after finding speech pathology hard to break into.
- “I went broke, basically. I had like... two or three hundred dollars left... a friend of mine said... what are you going to do next week? ...Just come work with me temporarily.” (06:39-08:21)
Motivation for DevTools and TypeScript
- Why DevTools? Parallels between helping patients speak and empowering devs via tools.
- “...when I work on dev tools, I feel the feeling... you end up taking a person who maybe didn't feel empowered... and you give them this tool that kind of walks them through it...” (09:58-12:28)
- Ethics and Impact: The satisfaction comes from indirect, systemic empowerment.
- “...you may not even know them... there's this force multiplier when you work on something like dev tools, that you're changing the world in some kind of positive way...” (10:41-12:28)
Why Port Doom to TypeScript Types?
- “Love of the Game” & Learning: A “pointless” but immensely educational project.
- “There's no reason to do a thing like this necessarily... I learned more working on this project than in the prior 10 years.” (12:36-13:18)
- Doom Project in Brief: Created a TypeScript type that, when checked, produces a live frame of Doom—all evaluated purely in compile-time type checking!
- “I made a type that will create a frame of Doom by checking the type.” (15:03-16:24)
- Unexpected Professional Value: Despite being a meme, it delivered real debugging and technical value at work.
- “It's shocking how often Doom has come up. Like, I'm so glad that it's out now that I can tell my colleagues because there were a lot of times at work where they'd be like, how do you know this?” (13:33)
TypeScript Turing Completeness and Beyond
- On Turing Completeness:
- “Turing complete to me means nothing. Basically, I think it’s a useless concept... My proposal, programmers, my proposal to you, stop talking about Turing complete. Start talking about Doom complete.” (18:47-20:25)
- Doom as Practical Benchmark:
- “Can it run in Doom? is a way more interesting mathematical observation... if it can just run one frame of Doom in a human lifetime... that separates lots and lots of known Turing complete systems.” (20:27)
Practical TypeScript Type System Advice
- Keep It Simple: Most teams shouldn’t need ultra-complex types; default TypeScript with strict mode suffices.
- “If you find yourself writing very long types... you're probably in a position that requires you to take a step back... sometimes you need to just understand that we’re working with imperfect systems...” (21:43-23:44)
- Be Mindful of Team and Codebase Health: Only introduce advanced types if the team and project are ready.
- “Looking around you to see how your colleagues feel... is highly critical and often overlooked...” (25:03)
- “If you see type checking is taking a long time, or there's lots of TS ignores... that's a very objective sign of unhealth... focus on those things first...” (25:03-27:47)
- TS Ignore/TS Expect Usage: Occasionally necessary, but always explain why.
- “The best thing you can do first is in that exact moment describe why it has to be there... someone might come along later and go, oh well if that's the reason, actually that problem doesn't exist anymore...” (29:27-30:24)
- Lesser-known Gotchas: Turn on
exactOptionalPropertyTypes!- “It’s called exact optional property types. I’m going to... make a video on this... if you would just be so kind as to turn it on... it only increases the life and the experience of users that do have it on...” (30:47-32:11)
The Technical Details: Doom via TypeScript Types
- Type-Level Programming at Work: Used “type-level programming”—types as inputs, outputs, and transformers—to simulate the WebAssembly runtime at compile time, including arithmetic, memory, and instruction emulation.
- “You have types as inputs, types as outputs, types as transformers, so kind of functions... instructions like ‘add two numbers together’... you can create an encoding for lots of things...” (34:19-38:18)
- String-based Computation: Emulated binary math via string manipulations (e.g., reversing, adding, looping through characters), reminiscent of early-grade-school math procedures.
- “The whole engine is built off of three things... Add a character to a string, Remove a character from a string, and Look through the current values in a string and change them. That’s it.” (42:22)
- Test-Driven Survival: The real hero: an extensive test suite and fuzz testing for correctness.
- “An extremely, extremely overdone test suite. So the real hero of this project is the test suite.” (40:12)
- Resource Intensity: The project famously took "a year of 18-hour days" and required 90GB of memory per typical run.
- “...there were many literal 18 hour days and there were many days that were more like greater than 24 hour programming spans...” (38:25)
The Human Side: Community, Content, and Next Steps
- Michigan TypeScript: Created out of the lack of deep advanced TypeScript educational material and a desire for technical community and resource sharing.
- “I kept really, really wanting somebody to do that and nobody would do it. I thought this is weird because TypeScript is sufficiently mature at this point...” (48:25)
- Focuses on advanced topics, featuring various contributors, not just Dimitri.
- “I view it more as like a collective personally... not me, you know, 60 non Dimitri people. So I think that motivates me to continue.” (50:08)
- Upcoming Projects:
- Video series with Dan Vanderkam: One for each of his “83 specific ways to improve your TypeScript.”
- Another with Andrew Branch: A short explanatory video for every single
tsconfigoption. - “So Dan and I are going to be making videos on that sometime. The next project... with Andrew Branch... is to make a video for each tsconfig option... there’s a lot of options...” (52:34-55:21)
- No Plans for an Even Wilder Next Project: “Nothing. Yeah, I think I'm just going to, going to take a break. I don't think this is going to be something, something that I can ever do.” (52:34)
- Parallel Interests: Music as a side passion (played and recorded Doom covers for the video), and belief in the importance of hobbies beyond one’s main field.
- “...having other pursuits in life is a very important element to being proficient in a specific thing. I think that people who go deep in a particular area often... get hamstrung eventually...” (58:11-59:51)
Notable Quotes & Memorable Moments
- “Just because Typescript types are Turing complete doesn’t mean that you can... run a frame of Doom. Yeah, that was the idea.” – Dimitri Mitropoulos (20:45)
- “My proposal, programmers... stop talking about Turing complete. Start talking about Doom complete.” (20:25)
- “Typescript without strict mode is not Typescript in my mind. It’s some kind of compatibility mode for migrating projects.” (21:43)
- On Team Dynamics:
“People hate working with you because you’re forcing them to do things that make them uncomfortable... There are ways to solve that... but at the end of the day, if they’re not down for the experience, then you kind of have to work with that.” (28:11-28:33) - On Burnout:
“If I knew what I knew now, I would never try.” (52:34) - On Diversifying Interests:
“Doing other things and having other pursuits in life is a very important element to being proficient... It will make you a better software engineer. If you learn to cook or... knit or whatever.” (58:11-59:51)
Timestamps for Key Segments
- Dimitri’s Origin Story & Path to Software (01:41 – 09:34)
- DevTools & Motivation to Empower Others (09:34 – 12:28)
- Origin and Motivation for Doom-in-Typescript (12:28 – 16:24)
- Type System Turing Completeness & Doom (18:47 – 21:02)
- Practical TypeScript Use, Philosophy and Gotchas (21:38 – 34:19)
- How Doom runs in Typescript Types: Technical Deep Dive (34:19 – 47:40)
- Content Creation and Michigan TypeScript’s Role (48:25 – 55:21)
- On Next Steps, Music, and Personal Development (55:21 – End)
Further Resources
- Michigan TypeScript YouTube Channel
- [Michigan TypeScript Discord] (https://michigantypescript.com)
- SquiggleConf
- [Doom TypeScript Announcement Video](search YouTube: “Doom TypeScript Mitropoulos”)
- Effective TypeScript by Dan Vanderkam
Closing Notes
Dimitri’s journey underscores the value (and limitations) of extreme technical tinkering, the importance of knowing your team’s context, and the human side of developer tooling and community. For TypeScript engineers, the episode offers equal doses of inspiration, caution, and practical wisdom wrapped in the most improbable technical accomplishment: Doom running, not just everywhere, but in compile-time type checks.
