Jim Keller argues most people rely on 'recipes' rather than deep understanding, using a bread-cooking analogy to contrast procedural steps with underlying principles. He discusses the trade-off between repeatedly executing known recipes (efficient short-term) and investing time to unpack systems for deeper understanding (enables broader generalization and better long-term designs). In computer architecture he describes how incremental complexity hits limits and sometimes a rewrite/refactor yields designs that are both faster and simpler; he recommends substantial rethinking roughly every 3–5 years (saying every five years you should do one from scratch). He also notes he was a co-author on the x86-64 instruction set around 1998, and emphasizes organizational tensions between short-term business pressures and long-term technical redesigns.
Questions this video answers
1998.
Roughly every three to five years; he specifically says 'every five years you should do one from scratch.'
Chapters
So what have you learned about the human abstractions, from individual, functional human units to the broader organization? What does it take to create something special?
Well, most people don't think simple enough. All right, so do you know the difference between a recipe and the understanding? There's probably a philosophical description of this. So imagine you're going to make a loaf of bread. The recipe says, get some flour, add some water, add some yeast, mix it up, let it rise, put it in a pan, put it in the oven. It's a recipe. Understanding bread, you can understand biology, supply chains, grain grinders, yeast physics, you know, thermodynamics. Like, there's so many levels of understanding there. And then when people build and design things, they frequently are executing some stack of recipes. Right. And the problem with that is the recipes all have limited scope. Like, if you have a really good recipe book for making bread, it won't tell you anything about how to make an omelette. Right. But if you have a deep understanding of cooking, right. Then bread, omelets, you know, sandwich, you know, there's. There's a different, you know, way of viewing everything. And most people, when you get to be an expert at something, you know, you're. You're hoping to achieve deeper understanding, not just a large set of recipes to go execute. And it's interesting to walk groups of people because executing recipes is unbelievably efficient if it's what you want to do. If it's not what you want to do, you're really stuck. And that difference is crucial. And everybody has a balance of, let's say, deeper understanding recipes. And some people are really good at recognizing when the problem is to understand something deeply. Does that make sense?
It totally makes sense. Does every stage of development deep understanding on the team needed?
Well, this goes back to the art versus science question.
Sure.
If you constantly unpacked everything for deeper understanding, you never get anything done. And if you don't unpack understanding when you need to, you'll do the wrong thing. And then at every juncture, like, human beings are these really weird things because everything you tell them has a million possible outputs. Right. And then they all interact in a hilarious way. And then having some intuition about what do you tell them, what do you do? When do you intervene, when do you not? It's. It's complicated, Right. So it's. It's, you know, essentially computationally unsolvable.
Yeah, it's an intractable problem.
Sure.
Humans are a mess. But with deep understanding, do you mean also sort of fundamental questions of things like what is a computer? Or why? Like the why questions. Why are we even building this of purpose? Or do you mean more like going towards the fundamental limits of physics, sort of really getting into the core of the science?
Well, in terms of building a computer, think a little simpler. So common practice is you build a computer and then when somebody says I want to make it 10% faster, you'll go in and say, all right, I need to make this buffer bigger and maybe I'll add an ad unit or I have this thing that's three instructions wide, I'm going to make it four instructions wide. What you see is each piece gets incrementally more complicated and then at some point you hit this limit. Adding another feature or buffer doesn't seem to make it any faster. And then people say, well, that's because it's a fundamental limit. And then somebody else will look at it and say, well, actually the way you divided the problem up and the way the different features are interacting is limiting you. And it has to be rethought, rewritten. Right. So then you refactor it and rewrite it. And what people commonly find is the rewrite is not only faster, but half as complicated. From scratch. Yes.
So how often in your career, but just have you seen as needed, maybe more generally, to just throw the whole out, the whole thing out?
This is where I'm on one end of it every three to five years.
Which end are you on?
Wait, rewrite more often.
Rewrite. And three to five years is if.
You want to really make a lot of progress on computer architecture, every five years you should do one from scratch.
So where does the X8664 standard come in? How often do you.
I was the co author of that back in 98. That's 20 years ago.
Yeah, so that's still around.
The instruction set itself has been extended quite a few times.
Yes.
And instruction sets are less interesting than the implementation underneath. There's been on x86 architecture, Intel's designed a few, AMD designed a few very different architectures. And I don't want to go into too much of the detail about how often, but there's a tendency to rewrite it every, you know, 10 years and it really should be every five.
So you're saying you're an outlier in that sense in the rewrite more often. Rewrite more often.
Well, and here's.
Isn't that scary?
Yeah, of course. Well, scary to who?
To everybody involved. Because like you said, repeating the recipe is efficient. Companies want to make money. No individual engineers want to succeed. So you want to incrementally improve. Increase the buffer from 3 to 4.
This is where you get into diminishing return curves. I think Steve Jobs said this, right? So every, you have a project and you start here and it goes up and they have diminishing returns. And to get to the next level, you have to do a new one. And the initial starting point will be lower than the old optimization point, but it'll get higher. So now you have two kinds of fear. Short term disaster and long term disaster.
And you're, you're grown ups, right?
Like, you know, people with a quarter by quarter business objective are terrified about changing everything. And people who are trying to run a business or build a computer for a long term objective know that the short term limitations block them from the long term success. So if you look at leaders of companies that had really good long term success, every time they saw that they had to redo something, they did.
And so somebody has to speak up.
Or you do multiple projects in parallel. Like you optimize the old one while you build a new one. But the marketing guys are always like, promise me that the new computer is faster on every single thing. And the computer architect says, well, the new computer will be faster on the average, but there's a distribution of results and performance and you'll have some outliers that are slower. And that's very hard because they have one customer who cares about that one.
