Lex Fridman PodcastJohn Carmack: Doom, Quake, VR, AGI, Programming, Video Games, and Rockets | Lex Fridman Podcast #309
CHAPTERS
- 0:00 – 1:53
3D immersion and the “startle reflex” that games didn’t used to trigger
Carmack opens with a vivid memory: early first-person 3D could provoke a physical fear response in a way top-down games rarely did. He frames this as a key moment when he realized interactive 3D would become a profoundly powerful medium.
- •Early players had little experience navigating 3D spaces
- •First-person perspective creates visceral, reptile-brain reactions
- •Contrast with “god’s-eye view” games that kept players emotionally distant
- •Carmack’s early intuition that immersion would matter long-term
- 1:53 – 4:34
First code, GOTOs, and why “structured programming” isn’t a religion
Lex asks about Carmack’s first program and quickly pivots into the GOTO debate. Carmack argues GOTOs aren’t inherently evil—sometimes they’re the cleanest option when language features are missing—though they’re rare in modern codebases.
- •TRS-80 beginnings: printing his name and looping with GOTO
- •Why early BASIC pushed people into spaghetti code
- •Legitimate modern uses: error/cleanup paths, missing control-flow features
- •Carmack’s current code rarely uses GOTO, but low-level engine code may
- 4:34 – 5:43
Falling in love with computers: the “genie” that does exactly what you tell it
Carmack describes the scarcity of information in the pre-internet era and how he obsessively consumed whatever he could find. He explains the core magic of programming: precise commands that reliably produce powerful outcomes—if you’re careful.
- •Learning from libraries, magazines, and a few precious books
- •Computers as a “magical” deterministic tool (with monkey’s-paw caveats)
- •Early motivation: making games like arcade/Atari titles
- •The drive to make action games pushed him toward low-level techniques
- 5:43 – 12:09
Early optimization mindset: scrolling hacks and constraints that shaped game design
Carmack recounts a formative Apple II graphics hack: using text-scrolling mechanisms to move a low-res graphics screen. He generalizes this to a career-long theme—making desired experiences run 2–10x faster than naive approaches to unlock fun.
- •Apple II low-res graphics and exploiting hardware behavior to scroll
- •Why action games were historically limited by performance, not ideas
- •Optimization as the bridge between “possible” and “fun”
- •Modern machines enable naive implementations—but frontier tech (e.g., VR) still demands pushing limits
- 12:09 – 32:51
Choosing programming languages: Python for ML, C/C++ for “serious work,” and skepticism of over-abstraction
Lex presses Carmack on the “best language,” leading to a pragmatic tour: Python’s convenience (and performance traps), C++’s power, and lessons from functional programming. Carmack emphasizes maintainability and team handoff as central concerns, not just speed.
- •Python: incredible leverage, but loops can be orders of magnitude too slow
- •C++ remains Carmack’s default for performance-critical systems work
- •Functional ideas (Lisp/Haskell) improved his approach to mutable state
- •Simple languages (C, Go) can be easier for teams to understand than highly malleable ones
- •Mixing many languages in one project often creates organizational friction
- 32:51 – 42:58
Engineering for user value: metrics, trade-offs, and the danger of infinite resources
Carmack outlines a philosophy: technical decisions should flow from user value, not aesthetic attachment to architectures. He argues big companies can be harmed by excess resources if they stop making hard prioritization decisions, and he warns against “imaginary users.”
- •User value as the top-level objective for developers and teams
- •Metrics matter, but can create overhead and distort priorities
- •When resources feel infinite, teams avoid hard trade-offs (feature A vs B)
- •VR at Meta: enough real users exist to test ideas—don’t invent personas
- •Leadership styles: vision-driven “dictator” models vs Meta’s culture
- 42:58 – 54:06
Work habits and the hard-work debate: consistency, sleep, and obsession without burnout
Lex asks about Carmack’s most productive routines, prompting a candid discussion of hours, sleep, and long-term intensity. Carmack argues more work generally gets more done (with diminishing returns), and notes he’s never personally experienced burnout.
- •Decades-long routine: ~60 hours/week (10-hour days, 6 days)
- •No all-nighters as a norm: productivity drops after ~12 hours for him
- •Sleep as non-negotiable for quality output
- •Working longer increases output; marginal productivity declines but doesn’t invert quickly
- •Individual differences: some thrive on obsession; others need stricter balance
- 54:06 – 56:49
Pizza, Diet Coke, and the ritual of getting into “serious programming” mode
Carmack addresses long-running lore about his diet: daily pizza deliveries in early days and a continuing Diet Coke habit. He frames these less as nutrition strategy and more as ritual—signals that it’s time to focus.
- •Pizza as a symbol of “making it” after a cash-strapped youth
- •Long stretch of daily pizza deliveries during intense dev years
- •Diet Coke as a work ritual cue: “now I mean business”
- •He credits exercise and moderation more than any specific diet hack
- 56:49 – 1:11:48
Developer setup and tooling culture wars: why debuggers matter and IDE hostility is costly
Carmack contrasts game-dev tooling culture (debuggers/IDEs as default) with Silicon Valley’s frequent reliance on minimal editors and logging. He argues debuggers are essential for understanding complex systems, and shares his preference for Visual Studio and multi-monitor setups.
- •Game dev vs big-tech norms: IDEs/debuggers embraced vs avoided
- •“Read the code and think” doesn’t scale to huge systems
- •Debugger-first workflow: breakpoints, stepping, immediate inspection
- •Static analyzers and guardrails as ego checks—code is always statistically flawed
- •Triple monitors as a simple productivity win; otherwise a “pedestrian” setup
- 1:11:48 – 1:22:05
The .plan file: proto-blogging, transparent work logs, and learning from old notes
Carmack explains the UNIX ‘finger’ command and the .plan file as an early public-facing status page. What started as a to-do list became a work log and occasional essay stream, influencing early developer transparency before blogs became mainstream.
- •NeXT/UNIX culture shock after DOS-era development instability
- •How finger exposed a user’s .plan file across the network
- •From private to-do list to public dev log and mini-essays
- •Retrospective value: seeing technical and organizational blind spots
- •Example impact: OpenGL advocacy and long-tail influence on mobile/Web graphics APIs
- 1:22:05 – 1:54:58
Founding id Software roots: Softdisk, rapid monthly shipping, and the shareware epiphany
Carmack tells the origin story: contract work for Softdisk, moving to Shreveport, and meeting Romero and others who expanded his horizons. The “ship every month” cadence became a pressure-cooker that built skills, and the Apogee shareware model unlocked explosive growth.
- •Softdisk’s monthly disk-subscription model and early contract game work
- •Meeting John Romero and encountering a deeper programming community
- •Monthly deadlines as a skill-forging loop (iteration, finishing, shipping)
- •Nintendo-inspired scrolling breakthroughs and the Mario PC demo attempt
- •Apogee shareware trilogy model: episode 1 as a full-quality free ‘demo’
- •Early legal/ethical missteps of building a new company while still employed
- 1:54:58 – 2:01:45
Commander Keen and PC side-scrolling: clever EGA tricks, wraparound memory, and compatibility pain
Carmack describes how PC hardware constraints made smooth scrolling feel impossible—until specific EGA/VGA insights made it work. Commander Keen emerged from Tom Hall’s creative vision layered onto Carmack’s evolving scrolling technology, delivered at startling speed and success.
- •Design constraint: early ‘adaptive tile refresh’ required repetitive tile patterns
- •All-nighter: ‘Dangerous Dave in Copyright Infringement’ Mario-style demo
- •Commander Keen as Tom Hall’s world-building plus rapid engineering execution
- •Second scrolling method: exploiting 64K wraparound behavior for smooth updates
- •Real-world downside: Super VGA variants broke assumptions, requiring compatibility hitches
- 2:01:45 – 2:09:11
Hacker ethic, source code releases, and the tension between craft, credit, and sharing
Prompted by Lex, Carmack defines the hacker ethic as open information sharing and joy in others’ accomplishments. He explains id’s gradual move from releasing tools to releasing full source code, and reflects on how credit myths and memetics distort technical history.
- •Steven Levy’s ‘Hackers’ as a formative influence
- •Sharing isn’t zero-sum; community gains outweigh individual advantage loss
- •Releasing tools, then eventually full engine/source as a cultural statement
- •Game industry/modding communities can be surprisingly possessive about code
- •Misattribution examples (e.g., inverse square root) and why provenance gets messy
- 2:09:11 – 2:29:22
Wolfenstein 3D’s technical leap: ray casting, compiled scalers, and triggering true immersion
Carmack breaks down how early ‘3D’ was largely a 2D world viewed differently—yet the perspective shift produced a fundamentally new emotional impact. He explains the key engine techniques behind Wolfenstein 3D, and why he pivoted approaches to eliminate glitchy rendering behavior seen in earlier prototypes.
- •2D gameplay logic + first-person view = dramatically different player psychology
- •Ray casting explained: per-column rays until hitting a wall in a grid map
- •Compiled scalers: generating many specialized routines to scale sprites fast
- •Optimization roots in Apple II-era pre-shifted sprites and compiled shapes
- •Wolfenstein as “rock solid” compared to earlier jankier texture-mapped experiments
- 2:29:22 – 5:14:50
From Wolfenstein to Doom: richer design space, BSP trees, and the pain of epsilon/precision
Carmack explains why Wolfenstein’s creative space ‘tapped out’ and how Doom crossed a threshold into a far more expressive level-design universe. He introduces BSP trees as a key acceleration structure and describes the numerical precision (‘epsilon’) problems that emerge once geometry becomes freeform and angled.
- •Doom-level design as a more ‘Turing-complete’ creative space than Wolfenstein
- •Intermediate stepping stones: ports, Shadowcaster, floors/ceilings/lighting experiments
- •BSP trees for ordering geometry and enabling efficient rendering strategies
- •Epsilon/finite-precision issues from intersecting angled lines and snapping to fixed-point values
- •No single ‘true’ engine approach: competitors (e.g., Build engine) succeeded with different techniques
