John Carmack: Doom, Quake, VR, AGI, Programming, Video Games, and Rockets | Lex Fridman Podcast #309

John Carmack 0: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, uh, 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!" 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 that-

Lex Fridman 0:34 You weren't inside the game.

John Carmack 0:36 ... something hits your face, something in the back of your brain...

Lex Fridman 0:38 Yeah.

John Carmack 0:38 Some reptile brain thing is just going, "Oh, shit, something just happened." And that was one of those early points where it's like, "Yeah, this is gonna make a difference. This is going to be powerful and it's gonna matter."

Lex Fridman 0:52 The following is a conversation with John Carmack, widely considered to be one 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. 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 five hours, and still I could talk to John many, many more times, and we hope to do just that. This is the Lex Fridman Podcast. To support it, please check out our sponsors in the description and now, dear friends, here's John Carmack.

Lex Fridman 1:57 What was the first program you've ever written? Do you remember?

John Carmack 2:01 Yeah, I do. So, I remember being in a RadioShack going up to the TRS-80 computers and learning just enough to be able to do ten print "John Carmack." Um, I... And it's kind of interesting how, of course, I... You know, Kernighan 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? I'm gonna say my name." And then you learn how to do GOTO 10 and have it scroll all off the screen and that was definitely the first thing that I wound up doing on a computer.

Lex Fridman 2:39 Can I ask you programming advice? I was always told in the beginning that you're not allowed to use GOTO statements. That's really bad programming. Is this correct or not? Jumping around code, can- can- can we look at the philosophy and the technical, uh, aspects of the GOTO statement that seems so convenient, but is supposedly bad programming?

John Carmack 2:55 Well, so certainly 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. So, you had no choice but to use GOTOs. 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. Uh, you didn't have good editors or code exploration tools, so you would wind up fixing things in one place, add a little patch and... There's reasons why structured programming generally helps understanding, but GOTOs aren't poisonous. Sometimes they're the right thing to do. Uh, usually it's because there's, uh, a language feature missing, like nested breaks or something where it's... 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, but it is rare. I mean, if you grep through all of my code right now, um, I don't think any of my current code bases would actually have a GOTO. But, uh, deep within sort of the technical underpinnings of a major game engine, you're gonna have some GOTOs in a couple places probably.

Lex Fridman 4:07 Yeah, the infrastructure on top of... (sighs) Like, the closer you get to machine code, the more GOTOs you're gonna see, the more of these, like, hacks you're going to see because, uh, the set of features available to you in low-level programming languages is not... uh, 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, this is really something special that, uh

John Carmack 4:34 It really was something that was one of those love at first sight things-

Lex Fridman 4:38 (laughs) Okay.

John Carmack 4:38 ... where just really from the time that I understood what a computer was, even... Uh, I mean, I remember looking through old encyclopedias at the black and white photos of the IBM mainframes with 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, you know, devour everything. Whenever Time or Newsweek had some article about computers I would, like, cut it out with scissors and put it somewhere. It just... 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 gonna back talk you. It wasn't gonna have a different point of view. It was gonna carry out what you told it to do and if you had the right commands, you could make it do these pretty magical things.

Lex Fridman 5:43 And so what kind of programs did you write at first? So beyond the print John Carmack.

John Carmack 5: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, uh, a Superman comic that RadioShack commissioned to have, uh, it's like Superman had lost some of his super brain and kids had to use RadioShack TRS-80 computers to do calculations for it to help him kind of complete his heroics. And I'd find little things like that, um, and then get a few basic books to be able to kind of work my way up. And again, it was so precious back then. I had a couple books that would teach me important things about it. I had one book that I could start to little, 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 I'm... My goals in the early days was almost always making games of various kinds. You know, I had, uh, 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? Uh, get sword, attack troll," that type of thing, and that can be done in the context of Basic. Uh, 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, one of my first sort of major technical hacks that I was kind of fond of was on the Apple II computers, they had a, they had a mode called low resolution graphics, where of course all graphics were low resolution back then-

Lex Fridman 7:31 (laughs) Right.

John Carmack 7:31 ... but, you know, 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, uh, the arcade game Vanguard, just a scrolling game, and I wanted to just kind of have it scroll vertically up. And I could move a little ship around. You, 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 graphic screen were basically the same thing, 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, uh, that was, like, this first great hack that sort of had analogues later on in my career for a lot of different things. So I found out that I could draw a screen, I could do a line feed at the bottom. It 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 I, you know, which was interesting in that that played a big part later on in the id Software days as well.

Lex Fridman 8:53 So do efficient scroll, 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.

John Carmack 9:04 Yeah. Where so much of, until recently, uh, 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. And nowadays that works just fine. Computers are ludicrously fast, uh, 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 d- to happen, it just has to happen two to ten 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 know. 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, but I do generally, you know, I'm not gonna do the, the angry old man shaking my fist at the clouds bit where back in my day programmers had to do real programming. You know, it's, 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, to be able to figure out how to make your wishes happen.

Lex Fridman 10:35 Well, there's still... See, that's true, but let me put on my old man with a fist-

John Carmack 10:40 Yeah.

Lex Fridman 10:40 ... uh, hat and say that probably the thing that will define the future still requires you to operate at, 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 s- uh, maybe not literally, but sort of, uh, spiritually, to go to the limits of what the system is capable of.

John Carmack 11:08 Yeah, and that really was why virtual reality was, um, 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. Uh, 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 when it's standalone and you're basically using a cellphone 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 DN, uh, DMA accesses. But it is still definitely a different level than what a web developer or a, or even a PC Steam game developer usually has to work at. 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.

Lex Fridman 12:09 Let me ask you, uh, uh, sort of a, a big question about preference. What would you say is the best programming language? Your favorite, but also the best. 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 if, 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?

John Carmack 12:41 Everything has all the caveats about it. So what I use... So nowadays, I, I do program a reasonable amount of Python for AI/ML sorts of work. Uh, that's, I'm not a, a native Python programmer. It's something I came to very late in my career. I understand what it's good for. I-

Lex Fridman 12:58 But you don't dream in Python.

John Carmack 13:00 I do not. And it has some of those things where there are 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, you know?

Lex Fridman 13:19 Yes.

John Carmack 13:19 You can be as much slower as we've almost gotten faster in our, uh, you know, our pace of progress and all this other miraculous stuff.

Lex Fridman 13:27 So your intuition's about inefficiencies within the Python sort of...

John Carmack 13:30 It keeps hitting me upside the face where-

Lex Fridman 13:32 Yeah.

John Carmack 13:32 ... it just, 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, it's amazingly convenient and you just see stuff that people are able to cobble together by 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. 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, uh, template meta-programming sorts of things. I see a lot of train wrecks coming from some of that over-abstraction. Uh, I spent a few years really going kinda deep into the, kinda the historical Lisp work, uh, and the Haskell and some of the functional programming sides of things. And there's... 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, uh, 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 h- how fast it operates, but it's how can it bend and adapt as situations change? And then the thing that I've really been learning in my time at Meta with, uh, 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. So...

Lex Fridman 15:27 Is C++ a good language for handover between engineers?

John Carmack 15:32 Probably not the best. Uh, and there's some, uh, really interesting aspects to this where, in some cases, languages that are not, um, that are not generally thought well of for many reasons, like C is derided pretty broadly that, yes, obviously all of the security flaws that happen with the memory and, uh, unsafeness and, uh, and buffer overruns and the things that you've got there. But there is this underappreciated aspect too. 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.

Lex Fridman 16:08 Mm-hmm.

John Carmack 16:08 I think there's, you know, and there's some really, really well-written C code. Like, it's, 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." Uh, it's not hard for me to figure out what's, uh, you know, what I need to do to, to, you know, make whatever change that I need to. While you can have, you know, more significant languages like... It's a downside of Lisp where I don't regret the time that I spent with Lisp. I, I think that it, I-

Lex Fridman 16:38 (laughs)

John Carmack 16:38 ... it did help, you know, help my thinking about programming in some ways.

Lex Fridman 16:42 Yes.

John Carmack 16:42 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. And then a language like Racket, kind of one 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 one 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 till you educate yourself on all of these things that we've built on top of that." And it was interesting to see how, uh, 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." 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." So, uh, I wish that I had more opportunity for doing some work, uh...... in Go. Uh, Rust is the other modern language that everybody talks about that I'm not fit to pass judgment on. I've done, you know, a little bit beyond Hello World. I wrote some, like, video decompression work in Rust just as an exercise, but that was a few years ago and I haven't really used it since. You know, the best programming language is the one 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 one 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. So you've got JavaScript here and then you have, uh, C++ for real work, and then you may have Java interfacing with some other part of the Android system. And those are all kinda horrible things. And that was, you know, one thing that I... I remember talking with, uh, with Boz at Facebook about it where, like, "Man, I wish we coulda just said, 'We're only hiring C++ programmers.'" Um, and he just thought from the, from the Facebook Meta perspective, well, we just wouldn't be able to find enough. Uh, you know, 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, I kinda mentioned that to Elon one 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 wanna use. But right now, I guess, yeah, they're using JavaScript on a bunch of the, the SpaceX work for the UI side of things. When you go find UI programmers, they're JavaScript programmers.

Lex Fridman 19:37 I wonder if that's because there's a lot of JavaScript programmers. Because I, I do think that great programmers are rare. That it's not... Y- 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.

John Carmack 19:55 Yeah.

Lex Fridman 19:55 And so you have to really look at what you were speaking to, which is the fundamentals of a language. What does it encourage you... 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 (laughs) about your programming which-

John Carmack 20:15 Well, it expects you to be an adult.

Lex Fridman 20:16 It expects you to be an adult.

John Carmack 20:16 (laughs) It does not force you to.

Lex Fridman 20:18 And so it should... 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, uh, amend themselves to real-world systems. Let me ask you about this other language, JavaScript. So if we... You know, aliens visit in, in thousands of years and humans are long gone, something tells me that most of the systems they find will be running JavaScript. I kind of think that if the simula- if we're living in a simulation, it's riven- it's written in JavaScript. Um, you know, for the longest time, even still, JavaScript didn't get any respect. And yet, it runs so much of the world, an increasing number of the world. Is it possible that all, everything will be written in JavaScript one day?

John Carmack 21:16 So the engineering under JavaScript is really pretty phenomenal. Uh, the, 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 hu- to build huge apps in something like this, uh, without type systems and so on. Um, 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, you know, a braces and semicolon language. Uh, it's not hard for people to be trained in JavaScript and then understand the roots of where it came from, I think. 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, the virtues and costs of garbage collection. You will run into some-

Lex Fridman 22:19 Uh-huh.

John Carmack 22:19 ... people that are top-notch programmers that just say, "No, this is literally not a good thing." Uh, that-

Lex Fridman 22:24 Oh, because it makes you lazy?

John Carmack 22:25 Yes. That it makes you not think about things. And I do disagree. I think that the... there is so much objective data on the, the vulnerabilities that have happened in C and C++ programs, sometimes written by the best programmers in the world. 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." But that's not 99-plus percent of all the software in the world. So JavaScript is not terrible in those ways and I... And so much of programming is not the language itself. It's the infrastructure around every... you know, that surrounds it. All the libraries that you can get and the different stuff that you can... ways you can deploy it, um, 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, 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 one little JavaScript statement to turn into something visible in your web browser, it's very, very disquieting, just the, 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. 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 m- 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, uh, 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, this web page run a thousand times faster." You know, make this web app into a, a hardcore native application that starts up in 37 milliseconds and everything responds in less than one 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," uh, often being efficient is not really the best metric. And it's like, there's- 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, uh, 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 one of my, you know, I-... One of the directions I was considering swerving into was, uh, nuclear energy when I was kind of like, "What do I want to do next?" It was either gonna be, uh, cost-effective nuclear fission or artificial general intelligence.

Lex Fridman 26:10 (laughs)

John Carmack 26:10 And one of the, one of my pet ideas there is like, you know, people don't understand how cheap nuclear fuel is and there would be ways that, uh, you could be a quarter the efficiency or less, but if it wound up making your plant ten times cheaper, that could be a radical innovation in something like that. So there's, like, some of these thoughts around, like, direct fission fr- uh, energy conversion, you know, 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, uh, took it far because sometimes there's discontinuities, like around user reaction times. There are some points where the difference between operating in one second and 750 milliseconds, uh, 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, you know, it's just like doing your bidding instantly rather than you're giving it a command, twiddling your thumbs waiting for it to respond. So sometimes it's important to really crunch hard to get over some threshold but there are, 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, you know, they just don't want to buy that and more power to them. You know, if somebody just wants to say, "No, I'm going to be, um... My pride is in my work, 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 and you do pick your battles and you deploy your resources in the play that's going to give you sort of the best user value in the end.

Lex Fridman 28:00 Well, if you look at the evolution of life on Earth as a kind of, um, programming effort, it's, uh, it seems like efficiency isn't the thing that it's being optimized for. Like, natural selection is very inefficient but it, it kind of, uh, adapts and through the process of adaptation is 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. (laughs) It's like this giant mess that, you know, things naturally die off if they don't work and they, if they, 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, 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 and then that's very, kind of the evolutionary process.

John Carmack 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, the kind of hackers playing code golf to be one less instruction than the other person's multiply routine to kind of get through and, and it was so perfectly crafted, it was a crystal piece of artwork when you had a program because there just were not that man-... 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 gonna do billions and billions of programmable waits 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, um, biological evolution and things work. I... You know, on the one hand, it's, it's almost humbling how little programming code is in our bodies, you know? 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 and this is not, like, Shannon limit perfectly, uh, information dense, uh-... conveyances here. It's like these are messy codes, you know, they're broken up into amino acids, a lot of them don't do important things or they do things in very awkward ways. But it is this process of just accumulation on top of things and you need, you need scale. Both... You need scale for sort of the population for that to work out. And in the early days, in the, the '50s and '60s, the, the kind of ancient era of computers where you could count... When they say, like, when the internet started even in the '70s there were, like, 18 hosts or something on it. 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, uh, uh, when a startup invested in the wrong tech stack and things completely failed or failed to scale. But, you know, but good things do come out of it and it's interesting to see the, the memetic 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, the dominance of Unix and C and, uh, early examples of things like that. 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 whethe- whether it's mind space or programming techniques or anything.

Lex Fridman 31:50 Like, there's a site on Stack Exchange called Code Golf where people compete to, 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, um, that are masters of their craft really play with the limits of programming languages. It's really beautiful to see. And across all the different programming languages you get to see some of these weird programming languages and mainstream ones. Python... Difference between Python 2 and 3. You get to see the difference between C and C++ and Java and you get to see JavaScript, all of that. And i- it's kinda, (sighs) um, inspiring to see how much depth of possibility there is within programming languages that Code Golf kind of tasks reveal. M- most of us, if you do any kind of programming, you kinda do boring kind of very, uh, 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 l- uh, laden with, in those languages. So given that,

Lex Fridman 33:01 given that you are once again one of the greatest programmers ever, uh, what do you think makes a good programmer? Maybe a good modern programmer?

John Carmack 33:11 So I just gave a long rant/lecture at Meta, uh, to the TPM organization and my, my biggest point was everything that we're doing really should flow from user value. You know, all the good things that we're doing. It's like we're, we're not technical people. 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.

Lex Fridman 33:38 Mm-hmm.

John Carmack 33:38 It's 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, uh, but instead they're choosing to use our products. 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, uh... They've gone from something of lesser value, chosen to use your product and their life feels better for that, and if you've produced that economically, that's, that's a really good thing. Uh, you know, on the other hand, if you've spent ridiculous amounts of money, you've just kind of shoveled a lot of cash into a wood chipper there and you should maybe, you know, not feel so good about what you're doing. So being proud about, like, a specific architecture or specific technology or 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, 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. This user over there with the big smile on their face, uh, the moment of delight when something happened, there's a value that's happened there." I mean, if you... 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. Uh, we've improved things." So, you know, being a, you know, being a servant to the user is your job when you're de- when you're a developer. You want to be producing something that, uh, you know, other people are gonna 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. And it always has to be, uh, kind of divided. There's a ratio there where you... It's a problem at the big tech companies, you know, whether it's, you know, Meta, Google, Apple, Microsoft, uh, Amazon, companies that have almost infinite money. I, 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, uh, then my product will be better." And that sense that...... at certain points, it's certainly true that if you are really hamstrung by this, removing an obstacle will, will make a better product, make more value. But if you're not making your core design decisions in this fiercely competitive, uh, way where you're saying, "Feature A or feature B," you can't just say, "Let's do both," uh, because then you're not making a value judgment about them. You're just saying, "Well, they both seem good. I don't wanna necessarily have to pick out which one is better or how much better and tell team B that, uh, sorry, we're not gonna do this because A is more important." But that, um, 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, you know, super important.

Lex Fridman 37:04 Well, let me ask you about this, the big debates that you're mentioning of, uh, how to measure value. (sighs) Is it possible to measure it kind of, um, numerically, uh, or can you do the sort of Jony Ive, the designer route of imagining sort of, uh, 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 low- lower level thing for, like, Linux, you imagine a developer that might come across this and use it and become, uh, happy and better off because of it. So where do you land on those things? Is it measurable? So I imagine s- 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." And then I think there is a kinda... I mean, I, I admire the designer ethic of, like, think of a future that's, that's immeasurable and you try to make somebody in that future that's different from today happy.

John Carmack 38:17 So I do usually favor if you can get any kind of a, 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 rights, uh, 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. I mean, all of the-

Lex Fridman 38:47 From actual users-

John Carmack 38:48 Yeah.

Lex Fridman 38:48 ... using the thing, human beings using the thing, l- large number of human beings, and you get to see sort of ab- lo-

John Carmack 38:54 Yeah. So there's the-

Lex Fridman 38:54 ... of large numbers.

John Carmack 38:54 ... zero-to-one problem of when you're doing something really new, you do kind of have to make a guess. But one of the points that I've been making at Meta is we have more than enough users now that anything somebody wants to try in VR, we have users that will be interested in that. You do not get to make a completely greenfield, blue sky pitch and say, "I'm going to do this because I think it might be interesting." I challenge everyone. There are going to be people, whether it's, you know, working in VR on your, um, uh, like on your desktop replacement or communicating with people in different ways or playing the games, there, there are going to be probably millions of people, or at least in the... If you pick some tiny niche that we're not in right now, there's still gonna be thousands of people out there that have the headsets that would be your target market. And I tell people, "Pay attention to them." Don't invent fictional users. Don't, you know, make an Alice, Bob, Charlie, uh, that fits whatever matrix of, uh, of tendencies that you wanna break the market down to, because it's a mistake to think about imaginary users when you've got real users that you could be working with. But, you know, on the other hand, there is, there is value to having a kind of wholeness of vision for a product and, um, companies like Meta have... You know, they, uh, understand the trade-offs where you can have a company like SpaceX or, you know, Apple in the, the Steve Jobs era where you have a very powerful leading personality that, uh, you know, they can micromanage at a very low level and can say it's like, "No, that handle needs to be different," or that, uh, that icon needs... "Change the tint there." And they clearly get a lot of value out of it. They also burn through a lot of employees that have, uh, horror stories to tell about, uh, working there afterwards. My position is that you're at your best when you've got a leader that is at their limit of what they can kind of comprehend of everything below them, uh, and they can have an informed opinion about everything that's going on.... yeah, I definitely kinda wanted to be. There was a point where I did make a pitch. It's like, "Hey, make me VR dictator, and I'll go in, get shit done." Uh, um, and that's just... it's not in the culture at Meta, you know? And they, they understand the trade-offs. They, uh... and that's just not the way... that's not the company that they want, the team that they, uh, that they wanna do.

Lex Fridman 42:37 Yeah, it's fascinating 'cause VR, and we'll talk about it more, i- i- it's still, it's still unclear to me in what way VR will change the world. Because it does seem clear that VR will somehow fundamentally transform this world, and it's unclear to me how.

John Carmack 42:53 Yeah.

Lex Fridman 42:53 Yeah. And it's-

John Carmack 42:54 Let me know when you wanna get into that. (laughs)

Lex Fridman 42:56 (laughs) We- we will. Well, hold on a second.

John Carmack 42:58 Yeah.

Lex Fridman 42:58 So, uh, in the, uh... let's stick to the, the you being the best programmer ever. Okay,

Lex Fridman 43:03 in the early days, when you didn't have... when, when you didn't have adult responsibilities of leading teams and all that kinda stuff and you can focus on just being a programmer, what did a productive day in the life of John Carmack look like? How many hours at the keyboard? How much sleep? What was the source of calories that fueled the brain? Uh, what was it like? What time did you wake up?

John Carmack 43:27 So I was able to be remarkably consistent about what was good working conditions for me for a very long time. Um, I was never one of the programmers that, uh, that would do all-nighters, going through work for 20 hours straight. It's like my brain generally starts turning to mush after 12 hours or so. Um, but the hard work is really important, and I would work for, for decades. I would work 60 hours a week. I would work a 10-hour day, six days a week, and try to be productive at that. Now, my schedule shifted around a fair amount when I was young without any kids, uh, um, any other responsibilities. I was on one of those cycling schedules, where I'd kind of get in an hour later each day and roll around through the entire time, and I'd wind up kinda pulling in at 2:00 or 3:00 in the afternoon sometimes, and then working again past, you know, midnight or 2:00 in the morning. And that was, um, when it was just me trying to make things happen, um, and I was usually isolated off in my office. People generally didn't bother me much, uh, at id-, and I could get a lot of programming work done that way. I did settle into a more normal schedule when I was taking kids to school and things like that.

Lex Fridman 44:40 So kids were the forcing function that got you to wake up-

John Carmack 44:43 Yeah.

Lex Fridman 44:43 ... at s- uh, same time each day? (laughs)

John Carmack 44:44 And it's, it's not clear to me that there was a, much of a difference in the productivity with, uh, with that, where I kinda feel if I just get up when I feel like it, it's usually a little later each day. But I just recently made the focusing decision to try to push my schedule back a little bit earlier to getting up at 8:00 in the morning and trying to, to shift things around. Like, I'm, I'm often doing experiments with myself about what should I be doing to, to be more productive, and one of the things that I did realize was happening in recent months, where I would, I would go for a, a walk or a run. I, I cover, like, four miles a day, and, and I would usually do that just as the sun's going down at... here in Texas now, and it's still really damn hot. But I'd go out at 8:30 or something and cover the time there, and then the showering. And it was putting a hole in my day, where I would have still a couple hours after that, and sometimes my best hours were at night when nobody else is around, nobody's bothering me. But that hole in the day was a problem, so just a couple weeks ago, I made the pa-, the change to go ahead and say, "All right. I'm gonna get up a little earlier. I'm gonna do a walk or get out there first so I can have more uninterrupted time." So I'm still playing with factors like this as I kind of optimize my, my work efforts, but it's always been... you know, it's, it was 60 hours a week for a very long time. To some degree, I had a little thing in the back of my head where I was almost jealous of some of the programmers that would do these marathon sessions and, and I had... like Dave Taylor, one of the guys at Id, he would be one of those people that would fall asleep under his desk sometimes and all the, the kind of classic hacker tropes about things. And a part of me was, like, always a little bothered that that wasn't me, that I, I wouldn't go program 20 hours straight because I'm just... I'm falling apart and not being very effective after 12 hours. I mean, yeah, 12-hour programming, that's fine when you're doing that, but it never... you're not doing smart work much after, at least I'm not. But there's a range of people. I mean, that's something that a lot of people don't really get in their gut. Where there are people that work on four hours of sleep and are smart and can continue to do good work, but then there's a lot of people that just fall apart. So I do tell people that I always try to get eight hours of sleep. It's not this, you know, push yourself harder, get up earlier. I just do worse work, where, uh, you know, there's... you can work 100 hours a week and still get eight hours of sleep if you just kind of prioritize things correctly. But I do believe in working hard, working a lot. Um, there was a comment that a game dev made that, that I know there's a backlash against really hard work in a lot of cases, and I get into online arguments about this all the time. But he was basically saying, "Yeah, 40 hours a week, that's kind of a part-time job." And if you are really in it, you're doing what you think is important, what you're passionate about, working more gets more done. And I... it's just really not possible to argue with that if you've been around the people that, that work with that level of intensity and just say, it's like, "No, they should just stop." And we had... I kinda came back around to that a couple years ago, where I was using the fictional example of, all right, some people say, they'll say with a straight face, they think, "No, you, you are less productive if you work more than 40 hours a week." And they're generally misinterpreting things, where your, your marginal productivity for an hour after eight hours is less than in one of your peak hours-

Lex Fridman 48:09 Mm-hmm.

John Carmack 48:09 ... but you're not literally getting less done. There is a point where you start breaking things and getting worse, uh, worse behavior and everything out of it, where you're literally going backwards, but it's not at 8 or 10 or 12 hours. And the fictional example I would use was, imagine there's an asteroid coming to impact, you know, to, to crash into Earth, destroy all of human life. Uh, do you want-Elon Musk, or the people working at SpaceX that are building the interceptor that's going to, uh, to deflect the asteroid, do you want them to clock out at 5:00 because, damn it, they're just gonna go do worse work if they work another couple hours? And, you know, it seems absurd. And that's a hypothetical though, and everyone can dismiss that. But then when coronavirus was hitting and you have all of these medical personnel that are clearly pushing themselves really, really hard and I'd say it's like, "Okay, do you want all of these scientists working on treatments and vaccines and caring for all of these people? Are they really screwing everything up by working more than eight hours a day?" And of course people say I'm just an asshole to say something like that but it's, I, you know, it's the truth. Working longer gets more done.

Lex Fridman 49:17 Well, so that's kind of, uh, the layer one, but I- I'd like to also say that, uh, at least I believe depending on the person, depending on the task, working more and harder will make you better for the n- for the next week in those peak hours. So there's something about a deep dedication to a thing that kind of gets deep in you. So it's, it's, it's the, the hard work isn't just about the raw hours of productivity, it's the, it's the thing it does to you in the, in the weeks and months after too.

John Carmack 49:56 You're tempering yourself in some ways.

Lex Fridman 49:59 And I think, you know, it's like Yajiro dreams of sushi. If you really dedicate yourself completely to making the sushi, like to, to really putting in the long hours day after day after day, um, you become a true craftsman of the thing you're doing. Now there's, of course, discussions about are you sacrificing a lot of personal relationships? Are you sacrificing a lot of other possible things you could do with that time? But if you're talking about purely being a c- um, a master or a craftsman of your art that more hours isn't just about doing more, it's about becoming better at the thing you're doing.

John Carmack 50:37 Yeah, and I don't gainsay anybody that wants to work the minimum amount. They've got other priorities in their life. My only argument that I'm making, it's not that everybody should work hard, it's that if you want to accomplish something, working longer and harder is the path to getting it accomplished.

Lex Fridman 50:53 Well, let me ask you about this then. Uh, the, the mythical, uh, work/life balance. Is th- for an engineer it seems like that's one of the professions in the, for, for a programmer where working hard does lead to greater productivity in it. Um, but it also raises the question of, um, sort of personal relationships and all that kind of stuff, family, and... Um, how were you able to find work/life balance? Is there advice you can give, maybe even outside your yourself? Have you been able to arrive at any wisdom on this part in your-

John Carmack 51:31 So-

Lex Fridman 51:31 ... years of life now?

John Carmack 51:32 ... I do think that there's a wide range of people where different people have different needs. It's not a one-size-fits-all. I am certainly what works for me... I, I can tell enough that I'm, you know, I'm different than a typical average person in the way things impact me, the, you know, the things that I want to do. Uh, my goals are different and sort of the, the levers to impact things are different. Where, you know, I have literally never felt burnout and I know there's lots of brilliant, smart people that, that do world-leading work that get burned out and it's never hit me. Uh, you know, I've never been at a point where I'm like, "Um, I just don't care about this. I don't want to do this anymore." But I've always had the flexibility to work on lots of interesting things, you know. I can always just turn my gaze to something else and have a great time working on that. And so much of that, and so much of the ability to actually work hard is the ability to have multiple things to choose from and to use, use your time on the most appropriate thing. Like, there are, there are time periods where I am... It's the best time for me to read a new research paper that I need to really be thinking, you know, hard about it. Then there's a time that maybe I should just scan and organize my old notes because my, you know, I'm just not on top of things. And then there's the time that, all right, let's go, you know, bang out a few hundred lines of code for something. So switching between them has been, you know, real valuable.

Lex Fridman 52:57 So you a- always have kind of joy in your heart for all the things you're doing and that, that is a kind of work/life balance as a first sort of step.

John Carmack 53:04 Yeah, I do. I-

Lex Fridman 53:05 So you're always happy.

John Carmack 53:06 I do. I-

Lex Fridman 53:07 (laughs)

John Carmack 53:07 Yeah, I mean, and while-

Lex Fridman 53:07 Well, happy, you know... (laughs)

John Carmack 53:08 Yeah, I mean, it's like I... A lot of people would say that often I look like kind of a grim person, you know, with just sitting there with a, a neutral expression or even, like, knitted brows and a frown on my face as I'm staring at something. But it's-

Lex Fridman 53:19 That's what happiness looks like for you. (laughs)

John Carmack 53:20 Yeah. (laughs) It's, it's kind of true where th- that-

Lex Fridman 53:23 Yeah.

John Carmack 53:23 It's like, "Okay, I'm pushing through this. I'm making progress here." I am... You know, we... I know that doesn't work for everyone. I know it doesn't work for most people. I am... But what I am always trying to do in those cases is I don't want to let somebody that might be a person like that be told by someone else that, "No, don't try it. Don't even try that out as an option," where I, you know, work/life balan- balance versus kind of your life's work where there's a small subset of the people that can be very happy being obsessive about things and, you know, obsession can often get things done that just practical, prudent, pedestrian work won't, or at least won't for a very long time.

Lex Fridman 54:06 There's legends of, uh, your nutritional intake, uh, in the early days. Uh, wha- what can you say about, uh, sort of a- as a, you know, being a programmer as a kind of athlete-

John Carmack 54:17 Mm-hmm.

Lex Fridman 54:18 So what, (laughs) what, what was, uh, the nutrition that fueled-

John Carmack 54:21 So I have never been that great on, uh, on really paying attention to it where I'm good enough that I- I don't eat a lot, you know, I've never been, like, a big, heavy guy but...... uh, it was interesting where one of the things that I can remember being an unhappy teenager, not having enough money and, like, one of the things that bothered me about not having enough money is I couldn't buy pizza whenever I wanted to.

Lex Fridman 54:43 Yeah.

John Carmack 54:43 So I got rich and then I bought a whole lot of pizza. It was re- (laughs)

Lex Fridman 54:46 So that was the defining... Like, that's what being rich felt like, is you could buy a pizza.

John Carmack 54:50 There was a lot of the little things. Like, I could buy all the pizza and comic books and video games that, uh, that I wanted to. And it really didn't take that much but, uh, the pizza was one of those things. And it's absolutely true that for a long time I did software, I had a pizza delivered every single day. You know, the delivery guy, you know, knew me by name. And I didn't find out until years later that apparently I was such a good customer that they just never raised the price on me and I was using this six-year-old price for the pizzas that they were still kind of sending my way every day.

Lex Fridman 55:21 So you were doing, um, eating once a day?

John Carmack 55:24 Uh...

Lex Fridman 55:25 Or, or were you, uh-

John Carmack 55:26 It would be spread out, you know, you have a few pieces of pizza, you have some more later on and I'd maybe have something at home. Uh, it was... One of the nice things at Facebook Meta is they do... They feed you quite well, you get a different, I guess now it's DoorDash sorts of things delivered. But, uh, they take care of making sure that everybody does get well fed and I probably had better food tha- those six years that I was working in the Meta office there than I used to before. But I've... It's worked out okay for me. My health has always been good. I, I get a, a pretty good amount of exercise and, huh, and I don't eat to excess and I avoid a lot of other kind of not-so-good-for-you things. So I'm still doing quite well at my age.

Lex Fridman 56:05 Did you have a, um, a kind of, I don't know, spiritual experience with food or coffee or any of that kind of stuff? I mean, uh, you know, the programming experience, you know, with music and, or, or, like, I listen to brown noise on a program or, like, the creating an- an environment and the things you take into your body, just everything you construct can become a kind of ritual that empowers the whole process of the programming. Did you have that relationship with pizza or, um-

John Carmack 56:34 It would really be with Diet Coke. I mean there-

Lex Fridman 56:36 With Diet Coke?

John Carmack 56:36 ... still is that sense of, you know, drop the can down, crack open the can of Diet Coke-

Lex Fridman 56:40 Yeah.

John Carmack 56:40 ... all right, now I mean business. We're getting to work here.

Lex Fridman 56:44 Still, to this day-

John Carmack 56:45 Yeah.

Lex Fridman 56:45 ... is Diet Coke is still a part of... (laughs)

John Carmack 56:46 It's, yeah, probably e- eight or nine a day. (laughs)

Lex Fridman 56:49 Nice.

Lex Fridman 56:50 Okay, uh, what about your setup? How many screens? What kinda keyboard? Is there something interesting, what kind of I, uh, IDE? I- EMAX, Vim or something modern? Uh, Linux? What operating system? Laptop or any, any, any interesting thing that brings you joy?

John Carmack 57:07 So I kind of migrated cultures where early on, through all of game dev, there was sort of one culture there which was really quite distinct from the more, uh, the Silicon Valley venture, you know, uh-

Lex Fridman 57:17 Right.

John Carmack 57:18 ... culture for things. It's, they're different groups and they have pretty different mores in the way they think about things where... And I still do think a lot of the big companies can learn, uh, can learn things from the, the hardcore game development side of things, where it still boggles my mind how, um, how hostile to debuggers and IDEs that so much of them, the kind of big money, get billions of dollars, Silicon Valley venture-backed funds are.

Lex Fridman 57:44 Oh, that's interesting. Sorry, so you're saying, like, m- like, uh, big companies like Google and Meta are hostile to...

John Carmack 57:50 They are not big on debuggers and IDEs. Like, so much of it is, like, EMAX-

Lex Fridman 57:54 Why?

John Carmack 57:54 ... Vim for things. And we-

Lex Fridman 57:56 Huh.

John Carmack 57:56 ... just assume that debuggers don't work most of the time, I- for the systems and a lot of this comes from a sort of Linux bias on a lot of things where-

Lex Fridman 58:05 Hmm.

John Carmack 58:05 ... I did come up through the, the personal computers and then the DOS and then I- you know, Windows and, and it was Borland tools and then Visual Studio and th-

Lex Fridman 58:16 Do you appreciate debuggers?

John Carmack 58:18 Very much so. I mean, a debugger is how you get a view into a system that's too complicated to understand. I mean, anybody that thinks just read the code and think about it, that's an insane statement in the... You can't even read all the code on a big system. You have to do experiments on the system and doing that by adding log statements, recompiling and rerunning it, uh, is an incredibly inefficient way of doing it. I mean, yes, you can always get things done even if you're working with stone knives and, you know, and bear skins. That's, that is the mark of a good programmer is that given any tools, you will figure out a way to get it done. But it's amazing what you can do with sometimes much, much better tools where instead of just going through this iterative, uh, compile-run-debug cycle, you have the, you have the old Lisp direction of, like, you've got a REPL and you're working interactively and doing amazing things there. But in many cases, a debugger has a very powerful user interface that can stop, examine all the different things in your program, set all of these different breakpoints. And of course you can do that with GDB or whatever there, but this is one of the user interface fundamental principles where when something is complicated to do, you won't use it very often. There's people that will break out GDB when they're at their wits' end and they just have beat their head against a problem for so long, but for somebody that kind of grew up in game dev, it's like they were running it in the debugger anyways before they even knew there was a problem and you would just stop and see, you know, what was happening and sometimes you could fix things even before you, you know, even before you did one compile cycle. You could be in the debugger and you'd say, "Well, I'm just going to change this right here." And yep, that did the job and fix it and go on.

Lex Fridman 59:57 And for people who don't know, GDB is a sort of popular, I guess, Linux debugger, uh, f- primarily for C++ maybe?

John Carmack 1:00:04 Uh, they, they handle most of the languages but it's-

Lex Fridman 1:00:07 Okay.

John Carmack 1:00:07 ... you know, it's based on C as the, the original kind of Unix heritage.

Lex Fridman 1:00:10 And, but, and it's kind of like command line, it's not user-friendly, it's not v- it doesn't allow for clean visualizations and you're th- you're exactly right, so the... You're using this kind of debugger usually when you're at wits' end and there's a problem that you can't figure out why by just looking at the code, so you have to find it. That's how, I guess, normal programmers use it. But you're saying there should be tools that kind of visualize and help you as part of the programming process, just a normal programming process to un- to d- understand the code deeper by debugging it.

John Carmack 1:00:40 Yeah. When I'm working on, like, my C/C++ code, I'm always running it from the debugger, you know, just I type in the code, I, I run it many times. The first thing I do after writing code is set a breakpoint and step through the function. Now other people will say, it's like, "Oh, I do that in my head." Well, your head is a faulty interpreter-

Lex Fridman 1:00:57 Yes.

John Carmack 1:00:57 ... of all those things there and I've written brand new code, I want to step in there and I'm gonna single step through that, examine lots of things and see if it's actually doing what I expected it to.

Lex Fridman 1:01:08 It, it is a kind of...... companion, the debugger. Like, it, you're, you're now coding in an interactive way with another being. Uh, a debugger is a kind of dumb being, but it's a reliable being. It, uh, that is an interesting question of what role does AI play in that kind of, um, with codex and these kind of ability to generate code that m- might be, you might start having tools that understand the code in interesting, deep ways that can work with you.

John Carmack 1:01:37 I mean, there's, there's a whole spectrum there from, uh, static code analyzers and various kind of dynamic tools there up to AI that can conceivably grok these programs that no h- literally no human can understand. They're, they're too big, too intertwined and too interconnected. But it's not beyond the possibility of understanding, it's just beyond what we can hold in our heads as kind of mutable state while we're working on things. And, uh, and I'm a big proponent, again, of things like static analyzers and some of that stuff where you'll find some people that don't like being scolded by a program for how they've written something where it's like, "Oh, I know better." And sometimes you do, but that was something that I was, it was very, very valuable for me when, uh, and not too many people get an opportunity like this to have. This is almost one of those spiritual experiences as a programmer, an awakening to, um... The id Software code bases were a couple of million lines of code. And at one point I had used a few of the different analysis tools, but I made a point to really go through and scrub the code base using every tool that I could find, and it was eye-opening where we had a reputation for having some of the, the most robust, strongest code, you know, where there were some, you know, great things that I remember hearing from, like, Microsoft telling us about crashes on Xbox and we had this tiny number that they said were, were probably literally hardware errors. And then you have other significant titles that just have millions of faults that are getting recorded all the time. So I was proud of our code on a lot of levels, but when I took this code analysis squeegee through everything, it was, it was shocking how many errors there were in there, things that you can say, "Okay, this was, this was a copy/paste, not changing something right here." Lots of things that were, you know, the most, the most common problem was something in a, a printf format string that was-

Lex Fridman 1:03:28 Mm-hmm.

John Carmack 1:03:28 ... the wrong data type that could cause crashes there.

Lex Fridman 1:03:30 Mm-hmm.

John Carmack 1:03:30 And, you know, you really want the warnings for things like that. Then the next most common was missing a check for null that could actually happen, that could blow things up. And those are obviously, like, top C, C++ things. Everybody has those problems. But the long tail of all of the different little things that could go wrong there. And we had good programmers. And my own code, so that, that I'd be looking at, it's like, "Oh, I wrote that code. That's definitely wrong. We've been using this for a year and it's this submarine, you know, this mine sitting there waiting for us to step on." And it was humbling. It was, uh, and I reached the conclusion that anything that can be syntactically allowed in your language, if, um, it's gonna show up eventually in a large enough code base. Uh, you're not gonna... Good intentions aren't going to keep it from happening. You need automated tools and guardrails for things. And those start with things like static types and, or, you know, or even type hints in the more dynamic languages. But the people that rebel against that, that basically say, uh, "That slows me down doing that," there's something to that. I get that. I've written, you know, I've cobbled things together in a notebook. I'm like, "Wow, this is great that it just happened." But, "Yeah, that's kind of sketchy, but it's working fine, I don't care." It does come back to that, that value analysis, where sometimes it's right to not care. But when you do care, if it's going to be something that's going to live for years and is gonna have other people working on it, uh, and it's gonna be deployed to millions of people, then you want to use all of these tools. You want to be told, it's like, "No, you've screwed up here, here and here." And that does require kind of an ego check about things, where you have to, to be open to the fact that everything that you're doing is just littered with flaws. It's not that, oh, you occasionally have a bad day. It's just whatever stream of code you output, there is going to be a statistical regularity of things that you just make mistakes on. And, um, and I do think there's the whole argument about test-driven design and unit testing versus kind of analysis and different things. I am more in favor of the analysis and the stuff that just, like, you can't run your program until you fix this, rather than you can run it and hopefully a unit test will catch it in some way.

Lex Fridman 1:05:43 Yeah. In my private code I have asserts everywhere.

John Carmack 1:05:46 Yeah.

Lex Fridman 1:05:47 Uh, it just, there's something pleasant to me, pleasurable to me about sort of the dictatorial rule of, like, "This should be true at this point." And too many times I've made mistakes that shouldn't have been made. Th- and I would assume I w- I wouldn't be the kind of person that would make that mistake, but I keep making that mistake. Therefore, an assert really catches me, uh, really helps all the time. So my co-... I would say, like, 10 to 20% of my private code just for personal use is probably asserts. (laughs)

John Carmack 1:06:21 And they're active comments.

Lex Fridman 1:06:22 (laughs) They're th- they're active comments, yeah.

John Carmack 1:06:22 And it's one of those things that in theory they don't, they don't make any difference to the program. And if it was all operating the way you expected it would be, then i- they will never fire. But even if you have it right and you wrote the code right initially, then circumstances change, the world outside your program changes. And in fact, that's, that's one of the things where I'm kind of fond in a lot of cases of static array size declarations where I went through this period where it's like, "Okay, now we have general collection classes. We should just make everything variable." I... Because I had this history of in the early days you get Doom, which had some fixed limits on it. Then everybody started making crazier and crazier things and they kept bumping up the different limits, this many lines, this many sectors. Uh, and it seemed like a good idea, "Well, we should just make this completely generic. It can go, kind of go up to whatever." And-There's cases where that's the right thing to do but it also... The other aspect of the world changing around you is, it's good to be informed when the world has changed more than you thought it would.

Lex Fridman 1:07:25 Mm-hmm.

John Carmack 1:07:25 And if you've got a continuously growing collection you're never gonna find out. You might have this quadratic slowdown on something where you thought, "Oh, I'm only ever gonna have a handful of these," but something changes and there's a new design style and all of a sudden you've got 10,000 of them. So I kinda like, in many cases, picking a number, some, you know, nice, round power of two number and setting it up in there and having an assert saying, it's like, "Hey, you hit the, you hit this limit. You should probably think are, the choices that you've made around all of this still relevant if somebody's using 10 times more than you thought they would?"

Lex Fridman 1:08:00 Yeah, this code was originally written with this kinda worldview, with this kinda set of constraints. You were, you were, you were thinking of the world in this way. If something breaks, that means you gotta rethink the initial stuff. And that's, it's nice for it to, for it, for it to do that. Is there any stuff like a keyboard or-

John Carmack 1:08:20 So I'm fairly-

Lex Fridman 1:08:20 ... or monitors?

John Carmack 1:08:21 Yeah. I'm fairly pedestrian on a lot of that where I, I did move to triple monitors, like, in the last several years ago. I had been dual monitor for a very long time and I... And it was one of those things where probably years later than I should have, I'm just like, "Well, the video cards now generally have three output ports. I should just put the third monitor up there." That's been a, that's been a pure win, I've been very happy with that.

Lex Fridman 1:08:43 Yeah.

John Carmack 1:08:44 Um, but no, I don't have fancy keyboard or mouse or anything really going on like that.

Lex Fridman 1:08:48 So the key things is an IDE that has, uh, helpful debuggers, has helpful tools, so it's not the Emacs vim route, and then Diet Coke.

John Carmack 1:08:57 Yeah. So I did spend... You know, I spent, uh, one of my week-long retreats where I'm like, "Okay, I'm gonna make myself use, uh..." It was actually Classic vi, which I know people will say, "You should never have done that. You should've just used Vim, uh, directly." But, you know, I gave it the good try. It's like, "Okay, I'm being in kind of classic Unix developer mode here," and I worked for a week on it. I had used Anki to, like, teach myself the, uh, the different little key combinations for things like that. And in the end it was just like, all right, this was kind of like my Civil War reenactment phase, you know? It's like I'm going out there, doing it like they used to in the old days and it, it was kinda fun in that regard.

Lex Fridman 1:09:34 You're offending so many people right now.

John Carmack 1:09:35 (laughs) But it was-

Lex Fridman 1:09:36 They're screaming as they're listening to this.

John Carmack 1:09:38 So again, the out is that this was not modern Vim, but still.

Lex Fridman 1:09:42 Right. (laughs)

John Carmack 1:09:42 Uh, yes, I was very happy to get back to my Visual Studio at the end.

Lex Fridman 1:09:46 Yeah. I'm actually, I struggle with this a lot, um, because... So I use a Kinesis Keyboard and, um, I use Emacs primarily and I, I feel like I, I can th- exactly as you said, I can understand the code, I can navigate the code. There's a lotta stuff you could build within EmacS with, using Lisp. You can customize a lotta things for yourself to help you, uh, introspect the code, like, to, to help you understand the code and visualize different aspects of the code. You can even run debuggers. But it's, it's work and, uh, the world moves past you and the better and better IDEs that are constantly being built and that, that puts a kind of... I, I need to take the same kind of retreat as you're talking about but now I'm still fighting the Civil War.

John Carmack 1:10:30 Mm-hmm.

Lex Fridman 1:10:30 I need to kinda move into the 21st century.

John Carmack 1:10:33 And it does seem like the world is, or a large chunk of the world is moving towards Visual Studio Code-

Lex Fridman 1:10:38 Yeah.

John Carmack 1:10:39 ... which is kind of interesting to me. Again, it's the-

Lex Fridman 1:10:40 (laughs) Yeah.

John Carmack 1:10:41 ... JavaScript ecosystem on the one hand and IDEs are one of those things that you want to be infinitely fast. You want them to just kind of immediately respond and, like, I mean, heck, I've got... There's someone I know, um, an old-school game dev guy that still uses Visual Studio 6 and on a modern computer everything is just absolutely instant on something like that because it was made to work on a computer that's 10,000 or 100,000 times slower, so just everything happens immediately and all the modern systems just feel... No, they feel so crufty when it's like, "Oh, why is this refreshing the screen and moving around and updating over here and something blinks down there and you should update this?" And there's... You know, there, there are things that we've lost with that incredible flexibility but, uh, lots of people get tons of value from it and I am super happy that that seems to be winning over even a lot of the old Vim and Emacs people that they're kind of like, "Hey, Visual Studio Code's maybe, you know, not so bad." Uh, that may-

Lex Fridman 1:11:41 Yeah.

John Carmack 1:11:41 ... be the final peacekeeping solution where everybody is reasonably happy with, uh, with something like that.

Lex Fridman 1:11:48 So can you explain what a .plan file is and what role that played in your life? Does it still continue to play a role?

John Carmack 1:11:55 Back in the early, early days of id Software, uh, one of our big things that was unique with what we did is, uh, I had adopted NeXTStations or kinda NextStep systems from, uh, Steve Jobs' l, uh, out in the, out in the woods way from Apple company and, uh, they were basically... It was kind of interesting because I did not really have a background with the Unix system. So many of the people, they get, uh, immersed in that in college and, uh, you know, and that's... You know, that sets a lot of cultural expectations for them and I didn't have any of that, uh, but I knew that my background was... I was a huge Apple II fanboy, um, I was always a little suspicious of the Mac. I... It was not really what I, what kind of I wanted didn't-... to go with. But when Steve Jobs left Apple and started NeXT, uh, this computer did just seem like one of those amazing things from the future where it had all of this cool stuff in it. And we were still, back in those days, working on DOS. Everything blew up. You had reset buttons because your computer would just freeze. If you're doing development work, literally dozens of times a day. Your computer was just rebooting constantly. And so this idea of, yes, any of the, the UNIX workstations would have given a stable development platform where you don't crash and reboot all the time. But NeXT also had this really amazing graphical interface and it was great for building tools and it used, uh, Objective-C as the kind of an interesting-

Lex Fridman 1:13:21 Oh, wow.

John Carmack 1:13:21 ... yeah, dead input things like that.

Lex Fridman 1:13:23 So, so NeXT was UNIX-based. It's at Objective-C. So it has a lot of the elements-

John Carmack 1:13:27 That became Mac. I mean, the-

Lex Fridman 1:13:28 Yeah.

John Carmack 1:13:29 ... kind of reverse acquisition of Apple by NeXT where that took over and became what, uh, what the modern Mac system is.

Lex Fridman 1:13:35 And defined some of the developer, um, like, uh, the tools and the whole community and the infrastructure.

John Carmack 1:13:41 Yeah, you've still got... If you're programming on Apple stuff now, there's still all these NS somethings, which was originally NeXTSTEP objects of different kinds of things. But one of the, the aspects of those old, those UNIX systems was they had this notion of a dotplan file where, you know, a dotfile is a, you know, an invisible file, u- uh, li- usually in your home directory or something. And there was a Trivial server running on most UNIX systems at the time that, uh, that when somebody ran a trivial little command called Finger, you could do Finger and then somebody's address. It could be anywhere on the internet if you were connected correctly. Then all that server would do was read the, the dotplan file in that user's home directory and then just spit it out to you. And originally, the idea was that could be, uh, whether you're on vacation, what your current project was. It's supposed to be like the plan of what you're doing. And people would use it for, you know, various purposes. But all it did was dump that file over the, to the terminal of whoever issued the, the Finger command. And at, you know, at one point, I started just keeping a, a list of what I was doing in there, which would be what I was working on in the day and I would have this little, uh, syntax I kind of got to myself about, uh, here's something that I'm working on. I put a star when I finish it. I could have a few other little bits of punctuation. And at the time, it was... It started off as being just like my to-do list and it would be these trivial, obscure little things like I, you know, fixed something with collision detection code, made Imp Fireball do something different, and just little one-liners that people that were following the games could kind of decipher. But I did wind up starting to write much more in-depth things. I would have, uh, little notes of, uh, thoughts and insights and then I would eventually start having little essays I would sometimes dump into the dotplan files interspersed with the work logs of things that I was doing. So in some ways, it was like a super early proto blog where I was just kind of dumping out what I was working on. But it was interesting enough that there were a lot of people that, uh, that were interested in this. So most of the people didn't have UNIX workstations so there were the websites, uh, back in the day that would follow the Doom and Quake development that would, uh, would basically make a little service that would go grab all the changes and then people could just get it with a web browser. And there was a period where, like, all of the little kind of Dallas gaming diaspora of people that were at all in that orbit, there were a couple dozen plan files going on which was... And this was some years before blogging really became kind of a thing and it was kind of a, um, a premonition of sort of the way things would go. And there was, uh... It's all been collected. It's available online in different places and it's kind of fun to go back and look through what I was thinking, uh, what I was doing in the different areas.

Lex Fridman 1:16:32 Have you had a chance to look back? Is there some interesting very low level specific to-do items, maybe things you've never completed, all that kind of stuff, and high level philosophical essay type of stuff, uh, that, that, that stands out?

John Carmack 1:16:45 There's some, yeah, there's some good stuff on both where a lot of it was low level nitpicky details about game dev and, um, you know, I've learned enough things where there's no project that I worked on that I couldn't go back and do a better job on now. I mean, you just, you learn things hopefully. If you're doing it right, you learn things as you get older and you should be able to do a better job at all of the early things. And there's stuff in Wolfenstein, Doom, Quake that I'm like, "Oh, clearly I, I could go back and do a better job at this," whether it's something in the rendering engine side or how I implemented the, the monster behaviors or managed resources