- 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 gonna 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, thermodynamics, there's so many levels of understanding there.

And then when people build and design things, they frequently are executing some stack of recipes. 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 omelet.

But if you have a deep understanding of cooking, then bread, omelets, sandwich, there's a different way of viewing everything. And most people, when you get to be an expert at something, 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 wanna do, you're really stuck. And that difference is crucial. And everybody has a balance of, let's say, deeper understanding of 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 unpack 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. And then they all interact in a hilarious way. - Yeah, it's very nice. - 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 complicated.

- Right, so-- - It's 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? Like 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 wanna 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 add unit.

Or I have this thing that's three instructions wide, I'm gonna make it four instructions wide. And what you see is each piece gets incrementally more complicated. And then at some point you hit this limit, like 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 that different features are interacting is limiting you, and it has to be rethought, rewritten. 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 thing out? - This is where I'm on one end of it, every three to five years. - Which end are you on? - Rewrite more often.

- Rewrite, and three to five years is? - If you wanna really make a lot of progress on computer architecture, every five years you should do one from scratch. - So where does the x86-64 standard come in? How often do you? - I wrote the, I was the co-author of that spec 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, Ames designed a few, very different architectures.

And I don't wanna go into too much of the detail about how often, but there's a tendency to rewrite it every 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 the problem. - Isn't that scary? - Yeah, of course. Well, scary to who? - To everybody involved, because like you said, repeating the recipe is efficient. Companies wanna make money, no, individual engineers wanna succeed, so you wanna incrementally improve, increase the buffer from three to four.

- Well, 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 you have diminishing return. 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-- - So grown-ups, right? Like, 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, they're 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 'cause they have one customer who cares about that one. (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music) (upbeat music)