See all Lex Fridman transcripts on Youtube

Speaker 1

00:00

I remember the reaction where he had drawn these characters and he was slowly moving around and like people had no experience with 3D navigation. It was all still keyboard. We didn't even have mice set up at that time, but slowly moving, going up, picked up a key, go to a wall, the wall disappears in a little animation and there's a monster like right there and he practically fell out of his chair. It was just like, ah!

Speaker 1

00:22

And games just didn't do that. You know, the games were the God's eye view. You were a little invested in your little guy. You can be like, you know, happy or sad when things happen, but you just did not get that kind of startle reaction.

Speaker 2

00:34

You weren't inside the game.

Speaker 1

00:36

Something in the back of your brain, some reptile brain thing is just going, oh shit, something just happened. And that was 1 of those early points where it's like, yeah, this is going to make a difference. This is going to be powerful and it's going to matter.

Speaker 2

00:52

The following is a conversation with John Carmack, widely considered to be 1 of the greatest programmers ever. He was the co-founder of id Software and the lead programmer on several games that revolutionized the technology, the experience, and the role of gaming in our society, including Commander Keen, Wolfenstein 3D, Doom, and Quake. He spent many years as the CTO of Oculus VR, helping to create portals into virtual worlds and to define the technological path to the metaverse and meta.

Speaker 2

01:28

And now he has been shifting some of his attention to the problem of artificial general intelligence. This was the longest conversation on this podcast at over 5 hours and still I could talk to John many many more times and we hope to do just that. This is the Lux Readment Podcast. To support it, please check out our sponsors in the description.

Speaker 2

01:52

And now, dear friends, here's John Carmack. What was the first program you've ever written? Do you remember?

Speaker 1

02:01

Yeah, I do. So, I remember being in a radio shack going up to the TRS-80 computers and learning just enough to be able to do 10 print John Carmack. And it's kind of interesting how, of course, Carnegan and Ritchie kind of standardized hello world as the first thing that you do in every computer programming language and every computer, but not having any interaction with the cultures of Unix or any other standardized things, it was just like, well, what am I gonna say?

Speaker 1

02:29

I'm gonna say my name. And then you learn how to do go to 10 and have it scroll all off the screen. And that was definitely the first thing that I wound up doing on a computer.

Speaker 2

02:39

Can I ask you a programming advice? I was always told in the beginning that you're not allowed to use go to statements. That's really bad programming.

Speaker 2

02:45

Is this correct or not? Jumping around code. Can we look at the philosophy and the technical aspects of the go-to statement that seems so convenient, but it's supposed to be programming? Well, so certainly

Speaker 1

02:56

back in the day in basic programming languages, you didn't have proper loops. You didn't have for, whiles, and repeats. You know, That was the land of Pascal for people that kind of generally had access to it back then.

Speaker 1

03:07

So you had no choice but to use go-tos. And as you made what were big programs back then, which were a thousand-line basic program is a really big program, They did tend to sort of degenerate into madness. You didn't have good editors or code exploration tools, so you would wind up fixing things in 1 place, add a little patch, and there's reasons why structured programming generally helps understanding. But gotos aren't poisonous.

Speaker 1

03:33

Sometimes they're the right thing to do. Usually it's because there's a language feature missing, like nested breaks or something, where it can sometimes be better to do a goto cleanup or goto error rather than having multiple flags, multiple if statements littered throughout things. But it is rare. If you grep through all of my code right now, I don't think any of my current codebases would actually have a go-to.

Speaker 1

03:59

But deep within sort of the technical underpinnings of a major game engine, you're gonna have some go-to's in a couple places probably.

Speaker 2

04:07

Yeah, the infrastructure on top of, like the closer you get to the machine code, the more go-to's you're gonna see, the more of these like hacks you're going to see, because the set of features available to you in low level programming languages is limited. So, print John Carmack, when is the first time, if we could talk about love, that you fell in love with programming. You said like, this is really something special.

Speaker 1

04:34

It really was something that was 1 of those love at first sight things where just really from the time that I understood what a computer was, even, I mean, I remember looking through old encyclopedias at the black and white photos of the IBM mainframes at the reel-to-reel tape decks. And for people nowadays, it can be a little hard to understand what the world was like then from information gathering, where I would go to the libraries and there would be a couple books on the shelf about computers, and they would be very out of date even at that point, just not a lot of information. But I would grab everything that I could find and devour everything.

Speaker 1

05:10

Whenever Time or Newsweek had some article about computers, I would cut it out with scissors and put it somewhere. It felt like this magical thing to me, this idea that the computer would just do exactly what you told it to. I mean, and there's a little bit of the genie monkey's paw sort of issues there where you'd better be really, really careful with what you're telling it to do. But it wasn't going to backtalk you.

Speaker 1

05:32

It wasn't going to have a different point of view. It was going to carry out what you told it to do. And if you had the right commands, you could make it do these pretty magical things.

Speaker 2

05:43

And so what kind of programs did you write at first? So beyond the print John Carmack.

Speaker 1

05:48

So I can remember as going through the learning process where you find at the start you're just learning how to do the most basic possible things. And I can remember stuff like a Superman comic that Radio Shack commissioned to have, it's like Superman had lost some of his super brain and kids had to use Radio Shack TRS-80 computers to do calculations to help him kind of complete his heroics. And I'd find little things like that and then get a few basic books to be able to kind of work my way up.

Speaker 1

06:20

And again, it was so precious back then. I had a couple books that would teach me important things about it. I had 1 book that I could start to learn a little bit of assembly language from, and I'd have a few books on BASIC and some things that I could get from the libraries. But my goals in the early days was almost always making games of various kinds.

Speaker 1

06:41

I loved the arcade games and the early Atari 2600 games, And being able to do some of those things myself on the computers was very much what I aspired to. And it was a whole journey where if you learn normal basic, you can't do any kind of an action game. You can write an adventure game. You can write things where you say, what do you do here?

Speaker 1

07:00

I get sword, attack troll, that type of thing. And that can be done in the context of basic I But to do things that had moving graphics there were only the most limited things you could possibly do you could maybe do breakout or Pong or that sort of thing in low resolution graphics And in fact 1 of my first sort of major technical hacks that I was kind of fond of was on the Apple II computers, they had a mode called low resolution graphics, where of course all graphics were low resolution back then. But regular low resolution graphics, it was a grid of 40 by 40 pixels normally, but they could have 16 different colors. And I wanted to make a game kind of like the arcade game Vanguard, just a scrolling game.

Speaker 1

07:44

And I wanted to just kind of have it scroll vertically up. And I could move a little ship around. You could manage to do that in basic, but there's no way you could redraw the whole screen. And I remember at the time just coming up with what felt like a brainstorm to me where I knew enough about the way the hardware was controlled, where the text screen and the low-resolution graphics screen were basically the same thing.

Speaker 1

08:07

And all those computers could scroll their text screen reasonably. You could do a listing and it would scroll things up. And I figured out that I could kind of tweak just a couple things that I barely understood to put it into a graphics mode, and I could draw graphics, and then I could just do a line feed at the very bottom of the screen, and then the system would scroll it all up using an assembly language routine that I didn't know how to write back then. So that was like this first great hack that sort of had analogs later on in my career for a lot of different things.

Speaker 1

08:37

So I found out that I could draw a screen, I could do a line feed at the bottom, we would scroll it up once, I could draw a couple more lines of stuff at the bottom, and That was my first way to kind of scroll the screen, which was interesting in that that played a big part later on in the id software days as well.

Speaker 2

08:53

So do efficient drawing where you don't have to draw the whole screen, but you draw from the bottom using the thing that was designed in the hardware for text output.

Speaker 1

09:04

Yeah. Where so much of, until recently, game design was limited by what you could actually get the computer to do. Where it's easy to say, like, okay, I want to scroll the screen. You just redraw the entire screen at a slight offset.

Speaker 1

09:19

And nowadays that works just fine. Computers are ludicrously fast. But up until a decade ago or so, there were all these things everybody wanted to do, But if they knew enough programming to be able to make it happen, it would happen too slow to be a good experience, either just ridiculously slow or just slow enough that it wasn't fun to experience it like that. So so much of kind of the first couple decades of the programming work that I did was largely figuring out how to do something that everybody knows how they want it to happen.

Speaker 1

09:51

It just has to happen 2 to 10 times faster than sort of the straightforward way of doing things would make it happen. And it's different now Because at this point, lots of things you can just do in the most naive possible way and it still works out. You don't have nearly the creative limitations or the incentives for optimizing on that level. And there's a lot of pros and cons to that.

Speaker 1

10:14

But I do Generally, I'm not going to do the angry old man shaking my fist at the clouds bit where back in my day programmers had to do real programming. It's amazing that you can just kind of pick an idea and go do it right now. And you don't have to be some assembly language wizard or deep GPU arcanist to be able to figure out how to make your wishes happen.

Speaker 2

10:35

Well there's still, see that's true, but let me put on my old man with a fist hat and say that probably the thing that will define the future still requires you to operate at the limits of the current system. So we'll probably talk about this, but if you talk about building the metaverse and building a VR experience that's compelling, it probably requires you to not to go to assembly or maybe not literally, but sort of spiritually to go to the limits of what the system is capable

Speaker 1

11:08

of. Yeah, and that really was why virtual reality was specifically interesting to me, where it had all the ties to, you could say that even back in the early days, I have some old magazine articles that's talking about Doom as a virtual reality experience back when just seeing anything in 3D. So you could say that we've been trying to build those virtual experiences from the very beginning. And in the modern era of virtual reality, especially on the mobile side of things.

Speaker 1

11:34

When it's standalone, you're basically using a cell phone chip to be able to produce these very immersive experiences. It does require work. It's not at the level of what an old school console game programmer would have operated at, where you're looking at hardware registers and you're scheduling all the DMA accesses. But it is still definitely a different level than what a web developer or even a PC Steam game developer usually has to work at.

Speaker 1

12:01

And again, it's great. There's opportunities for people that wanna operate at either end of that spectrum there and still provide a lot of value to the world.

Speaker 2

12:09

Let me ask you sort of a big question about preference. What would you say is the best programming language? Your favorite, but also the best.

Speaker 2

12:22

You've seen throughout your career, you're considered by many to be the greatest programmer ever. I mean, it's so difficult to place that label on anyone, but if you put it on anyone it's you. So let me ask you these kind of ridiculous questions of what's the best band of all time? But in your case, what's the best programming language?

Speaker 1

12:41

Everything has all the caveats about it, but so what I use, so nowadays I do program a reasonable amount of Python for AI ML sorts of work. That's I'm not a native Python programmer. It's something I came to very late in my career.

Speaker 1

12:56

I understand what it's good for.

Speaker 2

12:58

But you don't dream in Python.

Speaker 1

13:00

I do not. And it has some of those things where there's some amazing stats when you say if you just start, if you make a loop, you know, a triply nested loop and start doing operations in Python, you can be thousands to potentially a million times slower than a proper GPU tensor operation. And these are staggering numbers.

Speaker 1

13:19

You can be as much slower as we've almost gotten faster in our pace of progress and all this other miraculous stuff.

Speaker 2

13:26

So your intuition's about inefficiencies within the Python sort of-

Speaker 1

13:30

It keeps hitting me upside the face where it's gotten to the point now I understand it's like, okay, you just can't do a loop if you care about performance in Python. You have to figure out how you can reformat this into some big vector operation or something that's going to be done completely within a C++ library. But the other hand is, it's amazingly convenient, and you just see stuff that people are able to cobble together by, you just import a few different things, and you can do stuff that nobody on earth could do 10 years ago, and you can do it in a little cookbook thing that you copy-pasted out of a website.

Speaker 1

14:02

So that is really great. When I'm sitting down to do what I consider kind of serious programming, it's still in C++, and it's really kind of a C flavored C++ at that, where I'm not big into the modern template metaprogramming sorts of things. I see a lot of train wrecks coming from some of that over abstraction. I spent a few years really going kind of deep into the kind of historical Lisp work and Haskell and some of the functional programming sides of things.

Speaker 1

14:35

And there is a lot of value there in the way you think about things. And I changed a lot of the way I write my C and C++ code based on what I learned about the value that comes out of not having this random mutable state that you kind of lose track of. Because something that many people don't really appreciate till they've been at it for a long time is that it's not the writing of the program initially, it's the whole lifespan of the program. And that's when it's not necessarily just how fast you wrote it or how fast it operates But it's how can it bend and adapt as situations change?

Speaker 1

15:09

And then the thing that I've really been learning in my time at Meta with the oculus and VR work is It's also how well it hands off between a continuous kind of revolving door of programmers taking over maintenance and different things and how you get people up to speed in different areas and there's all these other different aspects of it.

Speaker 2

15:27

So C++ is a good language for handover between engineers?

Speaker 1

15:32

Probably not the best. And there's some really interesting aspects to this where in some cases, languages that are not, that are not generally thought well of for many reasons, like C is derided pretty broadly that yes, obviously all of these security flaws that happen with the memory and unsafeness and buffer overruns and the things that you've got there. But there is this underappreciated aspect to the language is so simple, anyone can go and, you know, If you know C, you can generally jump in someplace and not have to learn what paradigms they're using because there just aren't that many available.

Speaker 1

16:08

I think there's some really, really well-written C code. I find it great that if I'm messing around with something in OpenBSD, say. I mean, I can be walking around in the kernel and I'm like, I understand everything that's going on here. It's not hard for me to figure out what I need to do to make whatever change that I need to.

Speaker 1

16:30

While you can have more significant languages, it's a downside of Lisp where I don't regret the time that I spent with Lisp. I think that it did help my thinking about programming in some ways. But the people that are the biggest defenders of Lisp are saying how malleable of a language it is, that if you write a huge Lisp program, you've basically invented your own kind of language and structure because it's not the primitives of the language you're using very much. It's all of the things you've built on top of that.

Speaker 1

16:59

And then a language like Racket, kind of 1 of the more modern Lisp versions, it's essentially touted as a language for building other languages. And I understand the value of that for a tiny little project, but the idea of that for 1 of these long-term supported by lots of people kind of horrifies me, where all of those abstractions that you're like, okay, you can't touch this code until you educate yourself on all of these things that we've built on top of that. And it was interesting to see how when Google made Go, a lot of the criticisms of that are it's like, wow, this is not a state of the art language. This language is just so simple and almost crude.

Speaker 1

17:38

And you could see the programming language people just looking down at it. But it does seem to be quite popular as basically saying this is the good things about C. Everybody can just jump right in and use it. You don't need to restructure your brain to write good code in it.

Speaker 1

17:53

So, I wish that I had more opportunity for doing some work in Go. Rust is the other modern language that everybody talks about that I'm not fit to pass judgment on. I've done a little bit beyond Hello World. I wrote some video decompression work in Rust just as an exercise, but that was a few years ago and I haven't really used it since.

Speaker 1

18:15

The best programming language is the 1 that works generally that you're currently using. Because that's another trap is in almost every case I've seen when people mixed languages on a project, that's a mistake. I would rather stay just in 1 language so that everybody can work across the entire thing. And we have, like at Meta, we have a lot of projects that use kind of React frameworks.

Speaker 1

18:36

So you've got JavaScript here, and then you have C++ for real work, and then you may have Java interfacing with some other part of the Android system. And those are all kind of horrible things. And that was 1 thing that I remember talking with Boz at Facebook about it, where like, man, I wish we could have just said, we're only hiring C++ programmers. And he just thought from the Facebook meta perspective, well, we just wouldn't be able to find enough.

Speaker 1

19:05

With the thousands of programmers they've got there, it is not necessarily a dying breed, but you can sure find a lot more Java or JavaScript programmers. And I kind of mentioned that to Elon 1 time, and he was kind of flabbergasted about that. It's like, well, you just, you go out and you find those programmers and you don't hire the other programmers that don't do the languages that you want to use. But right now, I guess, yeah, they're using JavaScript on a bunch of the SpaceX work for the UI side of things.

Speaker 1

19:33

When you go find UI programmers, they're JavaScript programmers.

Speaker 2

19:36

I wonder if that's because there's a lot of JavaScript programmers, because I do think that great programmers are rare. That it's not, you know, if you just look at statistics of how many people are using different programming languages that doesn't tell you the story of what the great programmers are using. And so you have to really look at what you were speaking to, which is the fundamentals of a language.

Speaker 2

20:00

What does it encourage, how does it encourage you to think, what kind of systems does it encourage you to build? There is something about C++ that has elements of creativity but forces you to be an adult about your programming.

Speaker 1

20:14

It expects you to be an adult. It

Speaker 2

20:16

expects you to-

Speaker 1

20:17

It does not force you to.

Speaker 2

20:18

And so it brings out people that are willing to be creative in terms of building large systems and coming up with interesting solutions, but at the same time have the, sort of the good software engineering practices that amend themselves to real world systems. Let me ask you about this other language, JavaScript. So if we, you know, aliens visit in thousands of years and humans are long gone, something tells me that most of the systems they find will be running JavaScript.

Speaker 2

20:54

I kind of think that if we're living in a simulation, it's written in JavaScript. For the longest time, even still, JavaScript didn't get any respect, and yet it runs so much of the world and an increasing number of the world. Is it possible that all, everything will be written in JavaScript 1 day?

Speaker 1

21:16

So the engineering under JavaScript is really pretty phenomenal. The systems that make JavaScript run as fast as it does right now are kind of miracles of modern engineering in many ways. It does feel like it is not an optimal language for all the things that it's being used for, or an optimal distribution system to build huge apps in something like this without type systems and so on.

Speaker 1

21:45

But I think for a lot of people, it does reasonably the necessary things. It's still a C-flavored language. It's still a braces and semicolons language. It's not hard for people to be trained in JavaScript and then understand the roots of where it came from, I think.

Speaker 1

22:03

Garbage collection is unequivocally a good thing for most programs to be written in. It's funny that I still, just this morning I was on, I was seeing a Twitter thread of a bunch of really senior game dev people arguing about the virtues and costs of garbage collection. You will run into some people that are top-notch programmers that just say, no, this is literally not a good thing.

Speaker 2

22:24

Oh, because it makes you lazy?

Speaker 1

22:25

Yes, that it makes you not think about things. And I do disagree. I think that there is so much objective data on the vulnerabilities that have happened in C and C++ programs, sometimes written by the best programmers in the world.

Speaker 1

22:40

It's like nobody is good enough to avoid ever shooting themselves in the foot with that. You write enough C code, you're going to shoot yourself in the foot. And garbage collection is a very great thing for the vast majority of programs. It's only when you get into the tightest of real-time things that you start saying it's like, no, the garbage collection has more costs than it has benefits for me there.

Speaker 1

23:00

But that's not 99 plus percent of all the software in the world. So JavaScript is not terrible in those ways. And so much of programming is not the language itself. It's the infrastructure around everyone that surrounds it.

Speaker 1

23:17

All the libraries that you can get and the different stuff that you can, ways you can deploy it, the portability that it gives you. And JavaScript is really strong on a lot of those things where for a long time, and it still does if I look at it, the web stack about everything that has to go when you do something really trivial in JavaScript and it shows up on a web browser to kind of x-ray through that and see everything that has to happen for your 1 little JavaScript statement to turn into something visible in your web browser, it's very, very disquieting, just the depth of that stack and the fact that so few people can even comprehend all of the levels that are going on there. But it's, again, I have to caution myself to not be the in the good old days old man about it because clearly there's enormous value here. The world does run on JavaScript to a pretty good approximation there, and it's not falling apart.

Speaker 1

24:16

There's a bunch of scary stuff where you look at console logs and you just see all of these bad things that are happening, but it's still kind of limping along and nobody really notices. But so much of my systems design and systems analysis goes around, you should understand what the speed of light is, like what would be the best you could possibly do here. And it sounds horrible, but in a lot of cases, you can be a thousand times off your speed of light velocity for something and it still be okay. And in fact, it can even sometimes still be the optimal thing in a larger system standpoint where there's a lot of things that you don't want to have to parachute in someone like me to go in and say, make this webpage run a thousand times faster.

Speaker 1

25:01

Make this web app into a hardcore native application that starts up in 37 milliseconds and everything responds in less than 1 frame latency. That's just not necessary. And if somebody wants to go pay me millions of dollars to do software like that, when they can take somebody right out of a boot camp and say, spin up an application for this. Often being efficient is not really the best metric.

Speaker 1

25:26

It's like that applies in a lot of areas where It's kind of interesting how a lot of our appliances and everything are all built around energy efficiency, sometimes at the expense of robustness in some other ways or higher costs in other ways, where there's interesting things where energy or electricity could become much cheaper in a future world, and that could change our engineering trade-offs for the way we build certain things where you could throw away efficiency and actually get more benefits that actually matter. I mean, that's 1 of my – 1 of the directions I was considering swerving into was nuclear energy When I was kind of like, what do I want to do next? It was either going to be cost-effective nuclear fission or artificial general intelligence. And 1 of my pet ideas there is like, you know, people don't understand how cheap nuclear fuel is.

Speaker 1

26:18

And there would be ways that you could be a quarter the efficiency or less, but if it wound up making your plant 10 times cheaper, that could be a radical innovation in something like that. So there's like some of these thoughts around like direct fission energy conversion, fission fragment conversion that, you know, maybe you build something that doesn't require all the steam turbines and everything, even if it winds up being less efficient. So that applies a lot in programming where there's always, it's always good to know what you could do if you really sat down and took it far. Because sometimes there's discontinuities.

Speaker 1

26:54

Around user reaction times, there are some points where the difference between operating in 1 second and 750 milliseconds, not that huge. You'll see it in web page statistics, but most of the usability stuff, not that great. But if you get down to 50 milliseconds, then all of a sudden this just feels amazing. It's just like doing your bidding instantly rather than you're giving it a command, twiddling your thumbs, waiting for it to respond.

Speaker 1

27:19

So sometimes it's important to really crunch hard to get over some threshold, but there are broad basins in the value metric for lots of work where it just doesn't pay to even go that extra mile. And there are craftsmen that just don't want to buy that. And more power to them. If somebody just wants to say, no, I'm going to be, my pride is in my work.

Speaker 1

27:42

I'm never going to do something that's not as good as I could possibly make it. I respect that. And sometimes I am that person. But I try to focus more on the larger value picture.

Speaker 1

27:53

And you do pick your battles and you deploy your resources into play that's going to give you sort of the best user value in the end.

Speaker 2

28:00

Well, if you look at the evolution of life on Earth as a kind of programming effort, it seems like efficiency isn't the thing that's being optimized for. Like natural selection is very inefficient, but it kind of adapts and through the process of adaptations, building more and more complex systems that are more and more intelligent, the final result is kind of pretty interesting. And so I think of JavaScript the same way.

Speaker 2

28:30

It's like this giant mess that, you know, things naturally die off if they don't work. And if they're become useful to people, they kind of naturally live. And then you build this community, large community of people that are generating code and some code is sticky, some is not, and nobody knows the inefficiencies or the efficiencies or the breaking points, like how reliable this code is. And you kind of just run it, assume it works, and then get unpleasantly surprised.

Speaker 2

29:00

And then that's very kind of the evolutionary process.

Speaker 1

29:03

So that's a really good analogy. And we can go a lot of places with that, where in the earliest days of programming, when you had finite, you could count the bytes that you had to work on this. You had all the kind of hackers playing code golf to be 1 less instruction than the other person's multiply routine to kind of get through.

Speaker 1

29:20

And it was so perfectly crafted. It was a crystal piece of artwork when you had a program because there just were not that many – you couldn't afford to be lazy in different ways. And in many ways, I see that as akin to the symbolic AI work, where again, if you did not have the resources to just say, well, we're going to do billions and billions of programmable weights here, you have to turn it down into something that is symbolic and crafted like that. But that's definitely not the way DNA and life and biological evolution and things work.

Speaker 1

29:54

On the 1 hand, it's almost humbling how little programming code is in our bodies. We've got a couple billion base pairs, and it's like this all fits on a thumb drive for years now. And then our brains are even a smaller section of that. You've got maybe 50 megabytes.

Speaker 1

30:10

And this is not like Shannon limit, perfectly information dense conveyances here. It's like these are messy codes. They're broken up into amino acids. A lot of them don't do important things or they do things in very awkward ways.

Speaker 1

30:26

But it is this process of just accumulation on top of things. And you need scale. Both you need scale for the population for that to work out. In the early days, in the 50s and 60s, the ancient era of computers where you could count when they said like when the internet started even in the 70s, there were like 18 hosts or something on it.

Speaker 1

30:48

It was this small finite number and you were still optimizing everything to be as good as you possibly could be. But now it's billions and billions of devices and everything going on. And you can have this very much natural evolution going on where lots of things are tried, lots of things are blowing up, venture capitalists lose their money when a startup invested in the wrong tech stack and things completely failed or failed to scale. But good things do come out of it.

Speaker 1

31:17

And it's interesting to see the mimetic evolution of the way different things happen. Like mentioning Hello World at the beginning. It's funny how some little thing like that where everybody, every programmer knows Hello World now. And that was a completely arbitrary sort of decision that just came out of the dominance of Unix and C and early examples of things like that.

Speaker 1

31:38

So millions of experiments are going on all the time, but some things do kind of rise to the top and win the fitness war for whether it's mind space or programming techniques or anything.

Speaker 2

31:50

Like there's a site on Stack Exchange called Code Golf where people compete to write the shortest possible program for a particular task in all the different kinds of languages. And it's really interesting to see folks kind of, their masters of their craft really play with the limits of programming languages. It's really beautiful to see.

Speaker 2

32:14

And across all the different programming languages, You get to see some of these weird programming languages and mainstream ones, difference between Python 2 and 3. You get to see the difference between C and C++ and Java. You get to see JavaScript, all of that. And it's kind of inspiring to see how much depth of possibility there is within programming languages that code golf kind of tasks reveal.

Speaker 2

32:44

Most of us, If you do any kind of programming, you kind of do boring kind of very vanilla type of code. That's the way to build large systems. But it's nice to see that the possibility of creative genius is still within those languages. It's laden within those languages.

Speaker 2

33:00

So given that you are once again, 1 of the greatest programmers ever, what do you think makes a good programmer? Maybe a good modern programmer.

Speaker 1

33:10

So I just gave a long rant slash lecture at Meta to the TPM organization, and my biggest point was everything that we're doing really should flow from user value. All the good things that we're doing. It's like we're not technical people.

Speaker 1

33:28

It's like you shouldn't be taking pride just in the specific thing. Like code golf is the sort of thing, it's a fun puzzle game, but that really should not be a major motivator for you.

Speaker 2

33:38

It's

Speaker 1

33:38

like we're solving problems for people or we're providing entertainment to people. We're doing something of value to people that's displacing something else in their life. So we want to be providing a net value over what they could be doing, but instead they're choosing to use our products.

Speaker 1

33:53

And that's where, I mean, it sounds trite or corny, but I fundamentally do think that's how you make the world a better place. If you have given more value to people than it took you and your team to create, then the world's a better place. People have gone from something of lesser value, chosen to use your product, and their life feels better for that. If you've produced that economically, that's a really good thing.

Speaker 1

34:19

On the other hand, if you spent ridiculous amounts of money, you've just kind of shoveled a lot of cash into a wood chipper there, and you should maybe not feel so good about what you're doing. So being proud about a specific architecture or a specific technology or a specific code sequence that you've done, it's great to get a little smile, like a tiny little dopamine hit for that, but the top level metric should be that you're building things of value. Now, you can get into the argument about how you, you know, what is user value, how do you actually quantify that. And there can be big arguments about that, but it's easy to be able to say, okay, this pissed off user there is not getting value from what you're doing.

Speaker 1

34:58

This user over there with the big smile on their face, I am The moment of delight when something happened, there's a value that's happened there. You have to at least accept that there is a concept of user value. Even if you have trouble exactly quantifying it, you can usually make relative arguments about it. Well, this was better than this.

Speaker 1

35:17

We've improved things. So being a servant to the user is your job when you're a developer. You want to be producing something that other people are going to find valuable. And if you are technically inclined, then finding the right levers to be able to pull, to be able to make a design that's going to produce the most value for the least amount of effort.

Speaker 1

35:41

And it always has to be kind of divided. There's a ratio there where you – it's a problem at the big tech companies, whether it's MetaGoogle, Apple, Microsoft, Amazon, companies that have almost infinite money. I mean, I know their CFO will complain that it's not infinite money, but from most developers' standpoints, it really does feel like it. And it's almost counterintuitive that if you're working hard as a developer on something, there's always this thought, if only I had more resources, more people, more RAM, more megahertz, then my product will be better.

Speaker 1

36:16

And that sense that at certain points, it's certainly true that if you are really hamstrung by this, removing an obstacle will make a better product, make more value. But if you're not making your core design decisions in this fiercely competitive way where you're saying, feature A or feature B, you can't just say, let's do both. Because then you're not making a value judgment about them. You're just saying, well, they both seem good.

Speaker 1

36:42

I don't want to necessarily have to pick out which 1 is better or how much better and tell team B that sorry we're not going to do this because A is more important. But that notion of always having to really critically value what you're doing, your time, the resources you expend, even the opportunity cost of doing something else. That's super important.

Speaker 2

37:04

Well, let me ask you about this, the big debates that you're mentioning of how to measure value. Is it possible to measure it kind of numerically, or can you do the sort of Johnny Ive, the designer route of imagining sort of somebody using a thing and imagining a smile on their face, imagining the experience of love and joy that you have when you use the thing. That's from a design perspective, or if you're building more like a lower level thing for like Linux, you imagine a developer that might come across this and use it and become happy and better off because of it.

Speaker 2

37:50

So where do you land on those things? Is it measurable? So I imagine like Meta and Google will probably try to measure the thing. They'll try to, it's like you try to optimize engagement or something, let's measure engagement.

Speaker 2

38:03

And then I think there is a kind of, I mean, I admire the designer ethic of like, think of a future that's immeasurable, and you try to make somebody in that future that's different from today happy.

Speaker 1

38:17

So I do usually favor, if you can get any kind of a metric that's good, by all means, listen to the data. But you can go too far there where we've had problems where it's like, hey, we had a performance regression because our fancy new telemetry system is doing a bazillion file writes to kind of archive this stuff because we needed to collect information to determine if we were doing, you know, if our plans were good. So when information is available, you should never ignore it.

Speaker 1

38:46

I mean, all of

Speaker 2

38:47

it- For actual users using the thing, human beings using the thing, large number of human beings, and you get to see sort of at-

Speaker 1