Why performant code matters (but gets widely ignored), with Casey Muratori

Main Ideas, Concepts, and Lessons

1) Why “optimization” is often misunderstood

• A common (incorrect) optimization workflow is:
  • run a profile,
  • identify where time is spent,
  • make changes,
  • measure again.
• Casey’s claim: this approach is incomplete and often leads to local improvements rather than true optimization.

2) How to do real performance optimization (core methodology)

Casey argues the right approach is based on understanding limits and working toward them:

1. Enumerate the system’s required operations
   • Identify what the system must do (at an operation level).
2. Determine the underlying hardware’s theoretical capability
   • What is the CPU/GPU/network/hardware capable of at peak?
3. Measure the gap (“delta”)
   • Compare achieved performance vs. theoretical maximum.
4. Optimize to shrink the gap
   • Make changes with the goal of reducing unexplained performance loss.
5. Explain why you cannot reach theoretical peak
   • Often you’ll never hit peak; optimization is about narrowing the remaining unexplained gap.

Key warning: If you only iterate based on profiling feedback, you may just find a “good spot” and stop—i.e., local minima—which is not the same as reaching something close to an “optimal” ceiling.

3) “Napkin math / back-of-the-envelope” to detect benchmarking and reasoning errors

• Casey and other examples emphasize having baseline expectations for what should be “possible.”
• This helps detect:
  • incorrect benchmarks,
  • wrong bottlenecks being targeted,
  • architectural choices that cause huge hidden slowness.
• The purpose isn’t exact prediction—it’s to confirm whether results are plausible and whether the performance story makes sense.

4) Why reading assembly language matters for high-performance work

Casey’s reasoning:

• High-level languages don’t reveal what the CPU is actually asked to do.
• Assembly is the input language to the machine, so reading it lets you:
  • verify the CPU-level operations you’re triggering,
  • spot when performance is lost due to misunderstanding the generated code,
  • learn how hardware concepts (caches, instruction flow, branch prediction, execution throughput) map to real behavior.

He emphasizes assembly isn’t “hard” because:

• it has far fewer instructions/constructs than high-level stacks,
• compilers typically use only a small subset of those instructions for common work,
• optimization usually focuses on small code regions.

5) “Premature optimization” isn’t the blanket excuse people treat it as

Casey agrees the spirit behind “premature optimization” can be correct in some cases:

• if you can defer until you know an operation is actually a hotspot,
• if you understand the architecture won’t change and the final optimization target remains isolated.

But the problem arises when teams:

• make architectural choices assuming they can “fix it later,”
• accidentally create performance structures that are hard to optimize without rewriting.

Major example: serial dependency chains

• Many systems create “wait for server → do work → wait again → do work” patterns.
• This can make performance fundamentally constrained by the longest serial chain, which is not easily parallelizable.
• Fixing it may require rewriting the architecture, not just micro-optimizing a function.

6) Performance must be engineered for early, not “cleaned up” later

• “Hotspot cleanup” alone won’t save most codebases.
• Instead, teams need to design architecture and dependency choices so performance can be improved later.
• Performance regressions often come from language/runtime or system architecture decisions made when scaling requirements weren’t fully understood yet.

7) The role of primitives and data structures in latency and throughput

• The sponsors/messages include an example (via a sponsor story) about using a search engine as a serving index primitive to reduce sync latency:
  • the point: choosing the right primitives can reduce tail latency and keep it low even as change lists grow.
• Takeaway aligned with Casey’s theme: performance is shaped by the building blocks you select.

8) Clean code vs fast code: Casey’s view

• Casey discusses his video essay criticizing certain refactoring “clean code” rules (e.g., polymorphism-driven refactoring patterns).
• Core claim:
  • Many “clean code” prescriptions block compiler optimizations,
  • The cost is often not just the runtime overhead of virtual calls, but lost opportunities for compiler optimizations (inlining, code collapsing, vectorization, etc.).

He argues you can still write maintainable code, but you should avoid rules that prevent the compiler from producing efficient machine code.

9) Testing: pragmatic approach over dogma

• He supports testing when it saves time overall by catching:
  • bugs that are hard to find in production,
  • expensive-to-fix issues earlier.
• He dislikes “test-driven development” as a rigid default:
  • tests shouldn’t “drive” development by default,
  • but test strategy should be chosen intentionally based on cost/benefit.

10) Career-quality traits (non-negotiables)

Recurring themes for great software engineers:

• Curiosity and depth
  • ability/willingness to go deeper into layers of the stack,
  • not stopping at surface abstractions.
• Skepticism toward “received wisdom”
  • many practices are adopted without real measurement.
• Evidence-oriented thinking
  • prefer practices that have measurable practical upsides.
• Understanding how computers work at some level
  • unusual to be a “great” engineer without at least being able to read assembly / understand what the CPU is doing.

11) AI coding agents: why he isn’t using them (and broader implications)

• Casey says he is not using AI coding tools for his unreleased project.
• His reasons are philosophical/project-fit rather than purely productivity-based:
  • he wants to build/“program things in a game” himself,
  • using AI doesn’t align with the goals of the work (he suggests the same outcome could be achieved by using existing engines rather than agents, depending on intent).
• He suggests it’s too early to measure broad productivity impacts reliably:
  • current tooling still requires human workflow integration,
  • “pure autonomous shipping” isn’t mainstream,
  • early reports may be misleading or delayed by time needed to “bake” into reliable processes.
• He acknowledges “AI fatigue/burnout” is being reported by others:
  • autonomy may matter—people with more autonomy may use AI more positively,
  • people mandated to use AI may experience it as threat/control and lose motivation.

12) Games industry as a cautionary parallel (AI-era dynamics)

Casey describes how engine accessibility:

• reduced “engine risk,”
• enabled more creators to ship games,
• but also contributed to a market flooded with releases.

Result:

• game quality alone becomes insufficient for discovery,
• distribution/marketing becomes mandatory,
• “organic hit” probability decreases dramatically.

He suggests this is a hint for broader industries: lower barriers can increase volume, making differentiation harder.

---

Methodology / Instruction Lists (Detailed Bullets)

A) Casey’s “true optimization” workflow

• Identify all major operations the system must perform.
• Determine the theoretical peak capability of the relevant hardware (CPU/GPU/memory/network).
• Measure the performance gap (delta) between:
  • what the hardware should be able to do, and
  • what your system actually does.
• Optimize by making changes intended to reduce the unexplained gap.
• Investigate and document plausible explanations for why theoretical peak can’t be reached.
• Avoid treating “profiling + small change + better metric” as optimization by itself.
  • That may only find local improvements instead of approaching an optimal ceiling.

B) Architecture-level performance planning (avoid “rewrite later” traps)

• Ensure architectural decisions allow future optimization rather than foreclosing it.
• Watch for:
  • serial dependency chains that impose hard ordering constraints,
  • dataflow patterns that force “wait → request → compute → wait → request → compute…”
• Prefer designs that:
  • gather needed data earlier,
  • enable parallelism or batching where possible,
  • avoid structures that cannot be shortened without large rewrites.

C) Assembly-reading learning goals (what it enables)

• Learn to read assembly to:
  • map high-level code to CPU-level instructions,
  • verify what operations are actually executed,
  • judge whether the compiler can inline/collapse/vectorize effectively,
  • understand key hardware behaviors (cache, branches, execution throughput).

D) Pragmatic testing strategy

• Choose tests that reduce total time/cost by:
  • catching bugs early that are hard to detect in production,
  • preventing expensive regressions.
• Don’t treat “test-first” as an absolute rule.
• Evaluate:
  • cost to write/maintain tests,
  • cost to the codebase (tests that make refactoring harder),
  • overall time saved.

---

Speakers / Sources Featured

• Casey Muratori / Casey Moratory (primary guest; software/performance educator)
• Ryan (host; referenced in the intro request for the episode to be more programming-focused)
• Gerge (interviewer/host tone speaker name appears as “Gerge” in the discussion)
• Uncle Bob Martin (“Uncle Bob”) (referenced in discussion of “Clean Code” / polymorphism refactoring critique)
• Chris Hecker (referenced as a key figure in Windows gaming/graphics library origins)
• Michael Edwards (referenced as a manager providing cover for a graphics project)
• Angstrom and Alex St. John (referenced as institutional core contributors to DirectX)
• Rudy and Rajie (named as interns Casey mentioned reporting relationships with)
• Ron Gilbert (referenced regarding game development inspiration/visit)
• Antithesis (sponsor; agentic code verification and hostile simulation tooling)
• Sentry (sponsor; error monitoring/debugging with “autofix”)
• Turbopuffer (sponsor; vector/full-text search primitives used for serving/sync latency reduction)
• Linear (referenced as an example customer/story)
• Turbo buffer / Turbuffer (spelled variously; sponsor product referenced in the Linear story)
• Simon Erikson (founder of Turbopuffer; referenced for “Napkin Math” networking baseline idea)
• Armen Ronacher (referenced in discussion about AI autonomy/burnout perceptions)
• John (referenced as a friend; context: Casey helped with “The Witness”)
• AI tools discussed generally (no single named provider as a main speaking source, but OpenAI/Anthropic/Claude, etc., are mentioned in passing)