Lex Fridman PodcastJohn Carmack: Doom, Quake, VR, AGI, Programming, Video Games, and Rockets | Lex Fridman Podcast #309
EVERY SPOKEN WORD
150 min read · 30,009 words- 0:00 – 1:57
Introduction
- JCJohn Carmack
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-
- LFLex Fridman
You weren't inside the game.
- JCJohn Carmack
... something hits your face, something in the back of your brain...
- LFLex Fridman
Yeah.
- JCJohn Carmack
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."
- LFLex Fridman
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.
- 1:57 – 33:01
Programming languages
- LFLex Fridman
What was the first program you've ever written? Do you remember?
- JCJohn Carmack
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.
- LFLex Fridman
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?
- JCJohn Carmack
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.
- LFLex Fridman
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
- JCJohn Carmack
It really was something that was one of those love at first sight things-
- LFLex Fridman
(laughs) Okay.
- JCJohn Carmack
... 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.
- LFLex Fridman
And so what kind of programs did you write at first? So beyond the print John Carmack.
- JCJohn Carmack
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-
- LFLex Fridman
(laughs) Right.
- JCJohn Carmack
... 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.
- LFLex Fridman
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.
- JCJohn Carmack
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.
- LFLex Fridman
Well, there's still... See, that's true, but let me put on my old man with a fist-
- JCJohn Carmack
Yeah.
- LFLex Fridman
... 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.
- JCJohn Carmack
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.
- LFLex Fridman
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?
- JCJohn Carmack
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-
- LFLex Fridman
But you don't dream in Python.
- JCJohn Carmack
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?
- LFLex Fridman
Yes.
- JCJohn Carmack
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.
- LFLex Fridman
So your intuition's about inefficiencies within the Python sort of...
- JCJohn Carmack
It keeps hitting me upside the face where-
- LFLex Fridman
Yeah.
- JCJohn Carmack
... 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...
- LFLex Fridman
Is C++ a good language for handover between engineers?
- JCJohn Carmack
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.
- 33:01 – 43:03
Modern programming
- LFLex Fridman
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?
- JCJohn Carmack
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.
- LFLex Fridman
Mm-hmm.
- JCJohn Carmack
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.
- LFLex Fridman
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.
- JCJohn Carmack
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-
- LFLex Fridman
From actual users-
- JCJohn Carmack
Yeah.
- LFLex Fridman
... using the thing, human beings using the thing, l- large number of human beings, and you get to see sort of ab- lo-
- JCJohn Carmack
Yeah. So there's the-
- LFLex Fridman
... of large numbers.
- JCJohn Carmack
... 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.
- LFLex Fridman
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.
- JCJohn Carmack
Yeah.
- LFLex Fridman
Yeah. And it's-
- JCJohn Carmack
Let me know when you wanna get into that. (laughs)
- LFLex Fridman
(laughs) We- we will. Well, hold on a second.
- JCJohn Carmack
Yeah.
- LFLex Fridman
So, uh, in the, uh... let's stick to the, the you being the best programmer ever. Okay,
- 43:03 – 50:53
Day in the life
- LFLex Fridman
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?
- JCJohn Carmack
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.
- LFLex Fridman
So kids were the forcing function that got you to wake up-
- JCJohn Carmack
Yeah.
- LFLex Fridman
... at s- uh, same time each day? (laughs)
- JCJohn Carmack
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-
- LFLex Fridman
Mm-hmm.
- JCJohn Carmack
... 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.
- LFLex Fridman
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.
- JCJohn Carmack
You're tempering yourself in some ways.
- LFLex Fridman
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.
- JCJohn Carmack
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.
- 50:53 – 54:06
Hard work
- JCJohn Carmack
- LFLex Fridman
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-
- JCJohn Carmack
So-
- LFLex Fridman
... years of life now?
- JCJohn Carmack
... 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.
- LFLex Fridman
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.
- JCJohn Carmack
Yeah, I do. I-
- LFLex Fridman
So you're always happy.
- JCJohn Carmack
I do. I-
- LFLex Fridman
(laughs)
- JCJohn Carmack
Yeah, I mean, and while-
- LFLex Fridman
Well, happy, you know... (laughs)
- JCJohn Carmack
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-
- LFLex Fridman
That's what happiness looks like for you. (laughs)
- JCJohn Carmack
Yeah. (laughs) It's, it's kind of true where th- that-
- LFLex Fridman
Yeah.
- JCJohn Carmack
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.
- 54:06 – 56:50
Pizza and Diet Coke
- LFLex Fridman
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-
- JCJohn Carmack
Mm-hmm.
- LFLex Fridman
So what, (laughs) what, what was, uh, the nutrition that fueled-
- JCJohn Carmack
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.
- LFLex Fridman
Yeah.
- JCJohn Carmack
So I got rich and then I bought a whole lot of pizza. It was re- (laughs)
- LFLex Fridman
So that was the defining... Like, that's what being rich felt like, is you could buy a pizza.
- JCJohn Carmack
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.
- LFLex Fridman
So you were doing, um, eating once a day?
- JCJohn Carmack
Uh...
- LFLex Fridman
Or, or were you, uh-
- JCJohn Carmack
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.
- LFLex Fridman
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-
- JCJohn Carmack
It would really be with Diet Coke. I mean there-
- LFLex Fridman
With Diet Coke?
- JCJohn Carmack
... still is that sense of, you know, drop the can down, crack open the can of Diet Coke-
- LFLex Fridman
Yeah.
- JCJohn Carmack
... all right, now I mean business. We're getting to work here.
- LFLex Fridman
Still, to this day-
- JCJohn Carmack
Yeah.
- LFLex Fridman
... is Diet Coke is still a part of... (laughs)
- JCJohn Carmack
It's, yeah, probably e- eight or nine a day. (laughs)
- LFLex Fridman
Nice.
- 56:50 – 1:22:08
Setup
- LFLex Fridman
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?
- JCJohn Carmack
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-
- LFLex Fridman
Right.
- JCJohn Carmack
... 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.
- LFLex Fridman
Oh, that's interesting. Sorry, so you're saying, like, m- like, uh, big companies like Google and Meta are hostile to...
- JCJohn Carmack
They are not big on debuggers and IDEs. Like, so much of it is, like, EMAX-
- LFLex Fridman
Why?
- JCJohn Carmack
... Vim for things. And we-
- LFLex Fridman
Huh.
- JCJohn Carmack
... 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-
- LFLex Fridman
Hmm.
- JCJohn Carmack
... 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-
- LFLex Fridman
Do you appreciate debuggers?
- JCJohn Carmack
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.
- LFLex Fridman
And for people who don't know, GDB is a sort of popular, I guess, Linux debugger, uh, f- primarily for C++ maybe?
- JCJohn Carmack
Uh, they, they handle most of the languages but it's-
- LFLex Fridman
Okay.
- JCJohn Carmack
... you know, it's based on C as the, the original kind of Unix heritage.
- LFLex Fridman
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.
- JCJohn Carmack
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-
- LFLex Fridman
Yes.
- JCJohn Carmack
... 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.
- LFLex Fridman
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.
- JCJohn Carmack
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-
- LFLex Fridman
Mm-hmm.
- JCJohn Carmack
... the wrong data type that could cause crashes there.
- LFLex Fridman
Mm-hmm.
- JCJohn Carmack
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.
- LFLex Fridman
Yeah. In my private code I have asserts everywhere.
- JCJohn Carmack
Yeah.
Episode duration: 5:14:50
Install uListen for AI-powered chat & search across the full episode — Get Full Transcript
Transcript of episode I845O57ZSy4
Get more out of YouTube videos.
High quality summaries for YouTube videos. Accurate transcripts to search & find moments. Powered by ChatGPT & Claude AI.
Add to Chrome