Overview of Why performant code matters (but gets widely ignored), with Casey Muratori
This episode is a deep dive into software performance, engineering craft, and how technology shifts reshape entire industries. Casey Muratori argues that performance is often ignored not because it is unimportant, but because many developers lack the mental model to reason about what computers can actually do. He makes the case that good engineers should understand assembly, CPU behavior, and architecture-level trade-offs so they can avoid building software that is tens or hundreds of times slower than necessary.
Why performance gets ignored
Casey says performance is frequently neglected for a few reasons:
- The buyer often isn’t the user in enterprise software, so slow UX may not affect purchasing decisions.
- Network effects and monopolies make it hard for performance alone to displace incumbents.
- Many teams rely on the old advice that “premature optimization is the root of all evil”, which he считает is often used as an excuse to avoid thinking about performance at all.
He also notes that this is changing: more companies and developers are now benchmarking software, talking about latency, and using performance as a competitive advantage.
Casey’s core performance philosophy
A central point of the conversation is that optimization should not start with profiling random hotspots. Instead, Casey recommends:
- Identify what the hardware is theoretically capable of
- Measure the gap between that ideal and the current implementation
- Use that gap to guide optimization
His argument is that true performance problems often come from architecture, not micro-optimizations. A bad design can create:
- Serial dependency chains
- Unnecessary round trips
- Layouts that block parallelism
- Data access patterns that defeat caches
In other words, if the architecture is wrong, there may be no “quick fix” later.
Learning to write faster software
Casey strongly recommends learning to read assembly, even if you never write it by hand.
Why assembly matters
- It shows what the CPU actually receives, not what your high-level language suggests it does.
- It makes performance trade-offs visible.
- It helps you understand why some languages and abstractions are slower.
- It’s less intimidating than it sounds because you usually only need to learn a small subset of instructions.
What to learn next
He says a serious software engineer should also develop a working understanding of:
- CPU caches and memory hierarchy
- Branch prediction
- Instruction throughput and scheduling
- How data layout affects speed
His broader point: you do not need to be a “low-level wizard” to benefit from this knowledge. A few months of focused learning can dramatically improve how you design software.
“Clean code” vs. fast code
Casey discusses his controversial video on clean code and performance. His view is that many “clean code” rules are not inherently good engineering; they can actually block compiler optimizations.
His main critique
Rules like:
- always prefer polymorphism,
- split everything into tiny functions,
- hide type information at runtime,
can prevent the compiler from inlining, vectorizing, and simplifying code paths.
His definition of good code
Good code, in his view, is code that is:
- straightforward for the machine to execute
- easy for humans to understand
- structured so the compiler can still optimize it later
He doesn’t argue that maintainability and performance are opposites. Quite the opposite: he believes the best code is often both readable and fast.
Testing and pragmatic engineering
On test-driven development, Casey’s stance is pragmatic:
- Tests are valuable when they save time overall
- Development should not be blindly “driven by tests”
- The right testing strategy depends on the project
He emphasizes that engineers should understand:
- the cost of writing tests,
- the cost of maintaining them,
- and the risk of making code harder to change because of over-testing.
This fits his broader theme: avoid dogma, measure what matters, and make decisions based on actual trade-offs.
Lessons from the games industry
A big portion of the conversation looks at games as a case study in software evolution.
Early game development
When Casey was active in the industry:
- studios often built their own engines from scratch
- technical risk was enormous
- games were frequently judged by whether the engine could even support the intended design
- teams often had to prototype the “fun” under severe technical constraints
The rise of licensable engines
The spread of Unreal, Unity, and similar engines lowered the technical barrier to entry. That had two effects:
- Positive: many more people could make games
- Negative: the market became flooded, making discoverability much harder
His key takeaway: once engine risk disappeared, marketing and distribution became mandatory. A good game is no longer enough on its own.
Games as a parallel to AI
He sees a resemblance between licensed game engines and AI coding tools:
- both reduce the cost of creation
- both widen access
- both can flood the market with more output than the market can easily absorb
What changed in modern games
Casey notes that modern games, especially live-service titles, resemble SaaS more than the old “ship once and move on” model.
He points out that major titles like:
- Fortnite
- Roblox
- GTA Online
- Minecraft
are effectively long-lived platforms, not just standalone products.
Why GTA 6 takes so long
In Casey’s view, GTA 6 is not just “the next game” — it’s a replacement for a massively successful live-service revenue stream. That makes it a huge business risk, not just an artistic one. The studio has to ensure the new product can replace the old one without cannibalizing revenue.
AI, autonomy, and craft
Casey says his current project is not using AI coding tools, largely because the goal is to handcraft the work.
His broader AI view
- He thinks it is too early to judge AI’s full impact on software engineering
- He suspects a lot of current usage patterns will change
- He believes AI may eventually be seen as another “automation layer,” while handcrafted software remains a niche craft
He also makes an interesting social point:
- Engineers with more autonomy tend to react better to AI tools
- Engineers under mandates to use AI may feel threatened or demotivated
- That difference may be more about psychology and control than the tools themselves
Casey’s advice for improving as a developer
If you want to get better at performance and software craft, his advice is:
- Learn to read assembly
- Study how CPUs actually work
- Think in terms of theoretical maximums
- Watch for architectural mistakes early
- Read papers, not just books or blog posts
He encourages developers to search Google Scholar for topics in their domain and follow the references. His belief is that a lot of practical wisdom is buried in papers that most programmers never read.
Key takeaways
- Performance is often ignored for organizational reasons, not technical ones.
- Architecture matters more than micro-optimizations.
- Reading assembly is one of the fastest ways to improve your engineering intuition.
- Good code is not necessarily “abstract” code; it’s code the machine can run efficiently and humans can still reason about.
- In games, engine accessibility changed everything — but it also made marketing and distribution essential.
- AI may create a similar shift in software development, but the full impact is still uncertain.
- Curiosity, skepticism, and a willingness to go deeper into the stack are recurring traits of strong engineers.