Engineering Philosophy: John Carmack, Performance as Moral Craft

Key Takeaways

• Carmack treats performance as a moral question, not an optimization pass. The gap between your code and the physical limit of the hardware is waste, and waste is a choice.
• His method is subtractive: understand the problem to its foundation, strip it to the fast and simple core, and refuse every feature that slows that core.
• When the underlying problem changes, he rewrites from scratch. Quake threw away the engine that made id famous because real 3D was a different problem than faking it.
• He worked in the open – daily .plan logs, then open-sourced engines – on one conviction: code you will publish is code you write more honestly.

The Principle

“The speed of light sucks.” – John Carmack¹

It is a joke, and it is the whole philosophy. Carmack said it about network latency – the hard physical floor on how fast a packet can cross a continent – but the sentiment runs through every line he has written. The machine is governed by physics, and the engineer’s job is to get as close to the physical limit as the problem allows. Not close enough. As close as physics permits. Everything between the user and the speed of light is waste, and waste is a choice you made.

Carmack treats performance as a moral question rather than an optimization pass. Most software accumulates slowness the way a house accumulates clutter – one reasonable decision at a time, each defensible, the sum indefensible. Carmack’s discipline is to refuse the accumulation: understand the problem to its foundation, strip it to the fast and simple core, and ship that. The same conviction sits underneath the argument that performance is not a feature you add but a property you fail to lose – you do not optimize a slow system into a fast one; you build a fast one and defend it.

And he showed his work. For more than a decade Carmack published his daily engineering log – his .plan file – to the open internet, readable by anyone with a finger client.² The hardest 3D rendering problems of the 1990s were solved in public, in near real time. Working in the open was not marketing. It was the same instinct as the code itself: no hidden state, nothing you cannot inspect.

Context

John D. Carmack was born August 21, 1970, in Shawnee Mission, Kansas.³ He attended the University of Missouri–Kansas City for two semesters, then left to write software for a living. There was no formal apprenticeship and no degree. He learned graphics programming the way the demoscene did – by reading hardware manuals, measuring what the chip actually did, and writing assembly until the numbers came out right.

He landed at Softdisk, a software-and-disk-magazine company in Shreveport, Louisiana, working on a games subscription called Gamer’s Edge. There he met John Romero, Tom Hall, and Adrian Carmack (no relation). In September 1990 Carmack built a demonstration that should not have been possible on a PC: smooth, console-quality side-scrolling on EGA hardware. The IBM PC of 1990 redrew the whole screen on every frame – too slow for a scrolling game. Carmack’s technique, adaptive tile refresh, used obscure EGA hardware features to slide the already-drawn screen and repaint only the newly exposed edges.⁴ The team rebuilt the first level of Nintendo’s Super Mario Bros. 3 as a PC demo to prove it. Nintendo passed. The team kept the engine.

In February 1991 they left Softdisk to found id Software. The pattern was already set: find the problem nobody had solved, solve it at the hardware level, build the product on top of the solution. Carmack would do it again with texture-mapped 3D, then again with true polygonal 3D, then again with virtual reality. The milieu around him – Michael Abrash’s Graphics Programming Black Book, the cycle-counting culture of the demoscene – treated the processor as something to be understood exactly, not approximated. Carmack made that culture famous.

The Work

Commander Keen and Doom: The Fast Core (1990–1993)

Commander Keen in Invasion of the Vorticons (December 1990) was the first commercial game built on adaptive tile refresh. It mattered less as a game than as a proof: that a careful read of the hardware could close the gap between a general-purpose PC and a dedicated console. The smooth scroll was not a graphics trick layered on top. It was the engine.

Doom (1993) is the canonical example of Carmack’s method. To render its environments fast enough on a 1993 PC, he adopted binary space partitioning – BSP trees, formalized in a 1980 academic paper Carmack tracked down and adapted – to pre-compute the order in which walls had to be drawn, so the engine never overdrew a pixel it would later cover.⁵ Doom is not true 3D; it is a 2D map rendered with enough cleverness to feel volumetric. That distinction is the point. Carmack did not build the most general system. He built the system that ran fast on the hardware that existed, and refused every feature that would have slowed the core loop. The fast, simple core, shipped.

Quake: True 3D in Software (1996)

Quake (1996) was the rebuild from scratch. Where Doom faked depth, Quake rendered genuine three-dimensional polygonal worlds – sloped surfaces, looking up and down, real geometry – in software, before consumer 3D accelerators were common.⁶ The engine combined precomputed BSP visibility with offline lightmaps and hand-tuned assembly to do what the conventional wisdom said a CPU of that era could not. id later released GLQuake, an OpenGL renderer, that helped legitimize the consumer 3D graphics card.

Quake is the work where Carmack’s whole stance is visible at once: he threw away the engine that had made the company famous, understood the new problem (real 3D) to its foundation, and rebuilt. No reuse for its own sake. The previous solution was not sacred; the problem was.

The Open id Engines and the .plan Files (1997–2011)

Carmack did two unusual things with the code that made him rich. He published his daily work log – the .plan files – so the engineering was legible as it happened.² And then he gave the engines away. id open-sourced the Doom engine in 1997, Quake in 1999, and continued releasing the source to each generation of id Tech as the next shipped, through Doom 3 and beyond.⁷ His argument was plain: releasing old code lets younger developers learn how the thing was actually built, and “free software that people value adds wealth to the world.”⁸

That willingness is the part most performance-obsessed engineers never reach. Carmack’s craft was private discipline made public. The willingness to be read – to let anyone inspect the daily log and, eventually, the source – is itself a quality bargain. Code you will publish is code you write more honestly.

Oculus VR: The Latency Floor (2013–2019)

At Oculus, Carmack’s lifelong enemy – latency – became the entire problem. He wrote that “the latency between the physical movement of a user’s head and updated photons from a head mounted display reaching their eyes is one of the most critical factors in providing a high quality experience,” and that perceptible head-tracking latency “is also one of the primary causes of simulator sickness.”⁹ He set a budget – the goal was on the order of 20 milliseconds motion-to-photon – and treated every stage of the pipeline as a place to claw back microseconds. His timewarp technique reprojects an already-rendered frame at the last instant before display to absorb the head motion that happened during rendering.⁹ It is adaptive tile refresh again, twenty-three years later: do not redraw what you can reuse, and measure the result against the physical limit.

The Method

The method is consistent across thirty years and four problem domains.

Understand the problem to its foundation. Carmack reads the hardware manual, measures the actual behavior, and works from first principles rather than from convention. BSP trees, lightmaps, and timewarp were not in any playbook; they were derived from what the problem actually demanded.

Strip to the fast, simple core. Doom is not 3D because 3D was not needed to feel 3D on 1993 hardware. The discipline is subtractive: identify the inner loop, make it fast, and refuse the features that would slow it.

Rewrite from scratch when the problem changes. Quake did not extend the Doom engine. Carmack treats a working system as disposable the moment the underlying problem has moved. Sunk cost is not an argument.

Deep, uninterrupted focus. Carmack’s marathon coding sessions were never about endurance for its own sake. Holding an entire engine in working memory – the data layout, the inner loop, the edge cases all at once – takes hours to load and shatters the instant you context-switch. He protected that state the way he protected cycles in the render loop: as the scarce resource the work actually ran on.

Later: functional style in C. By the Doom 3 era and after, Carmack came to favor pure functions and minimized mutable state even in C and C++ – not for fashion, but because code without hidden state is code whose behavior you can predict, which means fewer bugs.¹⁰ It is the same instinct as the .plan files: nothing you cannot inspect.

Influence Chain

Who Shaped Him

Michael Abrash is the closest thing to a mentor in the lineage. Abrash’s writing on x86 graphics – later collected as the Graphics Programming Black Book – codified the cycle-counting, measure-everything culture that Carmack practiced. The two later worked together at id and, much later, at Oculus, where Abrash became chief scientist. (Direct influence)

The demoscene and the assembly-optimization culture of the late 1980s taught the foundational conviction: the processor is knowable exactly, and the gap between your code and the hardware ceiling is your responsibility. (Formative influence)

John Romero, his partner at id, was the complement rather than the teacher. Romero’s design and level work gave Carmack’s engines something worth running. The partnership is the reminder that a fast core is necessary, not sufficient – the engine exists to be played.

Who He Shaped

The entire game-engine industry. BSP visibility, lightmaps, and the open-sourcing of mature engines became baseline practice. A generation of engine programmers learned 3D rendering by reading id Tech source that Carmack chose to release.

Consumer 3D graphics hardware. Quake’s OpenGL path was an early commercial argument for the 3D accelerator card, helping to pull the GPU into the mainstream PC.

Modern virtual reality. Timewarp and the relentless latency budget are now standard vocabulary in every VR pipeline. The 20-millisecond target Carmack chased is the reason today’s headsets do not make people sick.

The Throughline

Andrej Karpathy rebuilds neural networks from scratch because understanding is not transferable – you have to derive it yourself. Carmack derives his renderers the same way: not from a framework, but from the hardware and the problem. And where Linus Torvalds prizes “good taste” – the special-case that dissolves into the general case – Carmack prizes the inner loop that does the least work physics allows. Both are the same conviction wearing different clothes: the right structure is not decoration on top of the problem; it is the problem, correctly seen. (Series bridge)

What I Take From This

The lesson I keep is that performance is honesty. A slow system is usually one whose author never understood the problem well enough to find its fast core – they assembled abstractions until it worked, and “worked” was where they stopped. Carmack stops at the physical limit instead. That is the same standard as quality being the only variable: the question is never “is this fast enough to ship?” but “do I actually understand why it is this slow?”

In the world I build in now – agents, tool loops, AI systems – the temptation is the opposite of Carmack’s discipline: stack frameworks, paper over latency with more model calls, never read what the system actually does. The Carmack move is to profile the loop, find the part that dominates, understand it to the foundation, and strip the rest. That conviction – that taste is a technical system you can measure, not a vibe you assert – is the throughline from a 1990 EGA scroll trick to a 2026 agent harness.

FAQ

What is John Carmack’s engineering philosophy?

Carmack treats performance as a moral question rather than an afterthought. The discipline is to understand a problem to its foundation, strip it to the fast and simple core, refuse the features that slow that core, and rewrite from scratch when the underlying problem changes. He pairs this with working in the open – publishing his daily engineering log and open-sourcing mature engines – on the conviction that code you can inspect is code written more honestly.²⁸

What did John Carmack build?

Carmack co-founded id Software in 1991 and was lead programmer on Commander Keen (1990, adaptive tile refresh), Wolfenstein 3D (1992), Doom (1993, BSP-based rendering), and Quake (1996, true 3D software rendering). He open-sourced the id Tech engines across two decades, served as CTO of Oculus VR where he drove the work on motion-to-photon latency, and later founded the AI company Keen Technologies.⁵⁶⁷⁹

What is adaptive tile refresh?

It is the technique Carmack devised in 1990 to achieve smooth side-scrolling on IBM PC EGA hardware, which was otherwise too slow because it redrew the entire screen each frame. Adaptive tile refresh slides the already-drawn screen using EGA hardware features and repaints only the newly exposed tiles at the edges, dramatically cutting the per-frame work. It made Commander Keen possible and established Carmack’s signature move: solve the bottleneck at the hardware level.⁴

Why did Carmack publish his .plan files and open-source his engines?

The .plan files were a daily engineering log, originally readable over the finger protocol, that documented id’s development in near real time.² Carmack later open-sourced each generation of id Tech once its successor shipped, arguing that releasing old code helps newer developers learn how games are really built and that valuable free software “adds wealth to the world.”⁸ Both practices reflect the same principle as his code: no hidden state, nothing you cannot inspect.

Sources