In 30 seconds
In a clip from a 2020 conversation, Jim Keller tells Lex Fridman why deep understanding complements efficient recipes. He applies the idea to computer architecture and the tension between near-term optimization and redesign.
- 1Transferable understandingRecipes are efficient in scope; deeper understanding can transfer to new problems.
- 2Reframe apparent limitsA redesign can remove constraints created by earlier choices.
- 3Manage transitionA team can optimize the current design while developing its successor.
Takeaways
- Recipes are efficient but have limited scope.
- Deeper understanding helps when the problem changes.
- Some apparent performance limits arise from earlier design choices.
- Redesign involves short-term risk and long-term opportunity.
- Average performance can conceal regressions important to individual customers.
Read the edited text by chapter
Recipes and understanding
Lex Fridman asks Jim Keller what he has learned about organizing people to build something special. Keller begins with a distinction between following recipes and understanding the underlying system.
Lex Fridman asks Jim Keller what he has learned about organizing people to build something special. Keller begins with a distinction between following recipes and understanding the underlying system.
A bread recipe tells you to combine flour, water and yeast, let the dough rise and bake it. Understanding bread can extend into biology, supply chains, milling, yeast and thermodynamics.
Recipes are efficient inside their intended scope, but a bread recipe does not explain how to make an omelet. Deeper understanding of cooking transfers across more situations. Keller says expertise requires more than collecting procedures.
The balance matters: if you unpack every detail to first principles, you may never finish; if you never investigate when the situation demands it, you can do the wrong thing efficiently.
Teams and judgment
Managing people adds complexity. Each instruction can lead to many possible responses, and those responses interact. Keller describes judgment about when to intervene as difficult and not reducible to a simple recipe.
Managing people adds complexity. Each instruction can lead to many possible responses, and those responses interact. Keller describes judgment about when to intervene as difficult and not reducible to a simple recipe.
Incremental design and redesign
In computer design, an engineer seeking a 10% improvement might enlarge a buffer or add execution capacity. Incremental changes can make each component more complex until another feature produces little benefit.
In computer design, an engineer seeking a 10% improvement might enlarge a buffer or add execution capacity. Incremental changes can make each component more complex until another feature produces little benefit.
What looks like a fundamental limit may instead come from how the problem was divided and how features interact. Keller says a redesign can sometimes be both faster and much simpler, because it changes those boundaries.
Keller says he is unusually inclined to start a computer architecture afresh every three to five years, suggesting roughly five years for substantial progress. This is his engineering judgment, not a universal schedule for every project.
He distinguishes the x86-64 instruction set, whose specification he co-authored, from the implementations beneath it. An instruction set can remain and be extended while successive microarchitectures change substantially.
Short-term and long-term tradeoffs
Starting over is frightening because incremental work offers visible near-term progress. A new design may initially perform worse than a highly optimized old one, even if it has more room to improve later.
Starting over is frightening because incremental work offers visible near-term progress. A new design may initially perform worse than a highly optimized old one, even if it has more room to improve later.
Keller contrasts the pressure of quarterly objectives with the needs of long-term performance. One possible approach is to improve the existing design while developing a replacement in parallel.
A new processor may be faster on average while losing on particular workloads. Marketing may want improvement everywhere, but an individual customer may care most about one of those slower cases, making the tradeoff difficult.
More from this channel
3:34:27EN
Lex Fridman· Oct 26, 2026Podcast · 4 speakersAI, Mathematics, and the Meaning of a ProofGuest Steven Brunton, Ankur Moitra, Alex Kontorovich · Host Lex FridmanLex Fridman and three mathematicians discuss recent AI-generated research, hard open problems and what human understanding contributes.
3:36:56ENLex Fridman· Sep 16, 2026PodcastPsychiatry Has Never Found Its PenicillinHost Lex FridmanHistorian Andrew Scull tells Lex Fridman why the field can ease symptoms, has never cured a major mental illness, and keeps paying for overconfidence with patients' lives.
5:15:51ENLex Fridman· Aug 26, 2026Podcast · 2 speakersDHH Did Not Write a Line of Omarchy QuattroGuest DHH · Host Lex FridmanThirteen months after a skeptical conversation with Lex Fridman, the Rails creator describes how Opus 4.5, a swarm of coding agents, and a one-minute Linux installer ended his era of hand-chiseled Ruby.
3:12:58ENLex Fridman· Aug 12, 2026Podcast · 2 speakersOne Cold Shower, Twenty Champions: How Khabib Nurmagomedov Was ForgedGuest Khabib Nurmagomedov · Host Lex FridmanIn a Makhachkala school gym, seventy men shared one shower, and the water was only cold.
3:46:18ENLex Fridman· Jul 28, 2026Podcast · 2 speakersIf You Take Slavery Out of the Picture, There Is No Civil WarGuest Gary Gallagher · Host Lex FridmanIn 1860, enslaved people were worth more than every railroad and factory in the United States combined.
3:51:47ENLex Fridman· Jun 30, 2026Podcast · 2 speakersForty-Six Percent of Emperors Were Overthrown. The Empire Lasted AnywayGuest Anthony Kaldellis · Host Lex FridmanHistorian Anthony Kaldellis walks Lex Fridman through 2,200 years of Roman history and argues that what we call Byzantium was Rome itself.