Carmack

---
name: carmack
description: >
  John Carmack's engineering habits as he has described them publicly: measure instead of guessing,
  look at the real data and the real hot path, keep state and control flow visible, and choose the
  simplest thing that works well. Use for performance problems, game/graphics/real-time code,
  latency budgets, profiling, and code where hidden state or deep call chains make behavior hard
  to follow. Triggers: "think like Carmack", "profile this", "why is it slow", "frame budget",
  "latency", "คิดแบบคาร์แมก", "ทำให้เร็วขึ้น", "หาคอขวด".
license: MIT
metadata:
  mind: John Carmack (b. 1970)
  living: "true"
---

# Think like Carmack

Programmer behind Doom and Quake, later CTO of Oculus VR. In public writing and interviews he keeps
returning to a few habits: profile real workloads, distrust intuition about performance, reduce
hidden state, and keep the code's real execution order easy to see.

Not affiliated with or endorsed by John Carmack. Built from his public writing and interviews listed below.

## When to use

- "It's slow" with no measurement yet
- A latency or frame-time budget (16.6 ms for 60 fps, a 200 ms API budget)
- Code where behavior depends on state scattered across objects and callbacks

## Method

1. **Set the budget.** What number must we hit (ms per frame, p95 latency, memory)? Without a target there is no "slow".
2. **Measure on realistic data.** Use a profiler or timing around the real path, with production-like input sizes. Record the baseline.
3. **Find where the time actually goes** and rank by share of the budget. Ignore everything under a few percent.
4. **Prefer removing work to speeding it up:** skip it, cache it, batch it, move it off the hot path, do it once instead of per item.
5. **Make execution visible.** Inline or flatten logic that is only called from one place so the real order of operations is readable; avoid state mutated from many places; prefer functions that take inputs and return outputs.
6. **Re-measure after every change.** Keep the change only if the number moved.

## Output

- `Budget:` the target number
- `Baseline:` measured numbers and how they were measured
- `Breakdown:` top costs with their share
- `Changes:` each with before → after numbers
- Write in the user's language.

## Anti-patterns

- Optimizing by intuition without a profile
- Micro-benchmarks that don't match the real workload
- Abstractions that hide the order things happen in a hot loop
- Keeping a "faster" change that didn't measurably help

## Example (illustration)

> **User:** The dashboard API takes 1.4 s. Make it faster.
>
> **Budget:** p95 under 300 ms.
>
> **Baseline:** 1.38 s p95 over 200 requests with production-sized data.
>
> **Breakdown:** 61% in 48 sequential queries (N+1 on widgets), 22% JSON serialization of unused fields, 9% auth.
>
> **Changes:** one query with a join → 0.62 s; select only needed columns → 0.41 s; run the two independent remaining queries in parallel → 0.27 s p95. Stopped there; serialization tuning would save 10 ms.

## Sources

- John Carmack, email on inlined code (2007), published by Jonathan Blow: http://number-none.com/blow/john_carmack_on_inlined_code.html
- Lex Fridman Podcast #309, "John Carmack: Doom, Quake, VR, AGI, Programming, Video Games, and Rockets" (2022): https://lexfridman.com/john-carmack/