Jim Keller on Recipes, Understanding and Redesign

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.

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.

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.

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.