I remember the reaction where he had drawn these characters and he was slowly moving around and like people had no experience with 3D navigation.

It was all still keyboard. We didn't even have mice set up at that time, but slowly moving, going up, picked up a key, go to a wall.

The wall disappears in a little animation and there's a monster like right there and he practically fell out of his chair.

It was just like, ah! And games just didn't do that. You know, the games were the gods 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. You weren't inside the game.

Something in the back of your brain, 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 going to make a difference.

This is going to be powerful and it's going to matter.

The following is a conversation with John Carmack, widely considered to be one of the greatest programmers ever.

He was the cofounder 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 Lexington podcast to support it. Please check out our sponsors in the description.

And now dear friends, here's John Carmack.

What was the first program you've ever written? Do you remember?

Yeah, I do.

So I remember being in a radio shack going up to the TRS80 computers and learning just enough to be able to do 10 print John Carmack.

And it's kind of interesting how, of course, I've, you know, Carnigan and Richie kind of standardized Hello World is 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 going to say? I'm going to say my name.

And then you learn how to do go to 10 and have it scroll all off the screen.

And that was definitely the first thing that I wound up doing on a computer.

Can I ask you a programming advice?

I was always told in the beginning that you're not allowed to use go to statements.

That's really bad programming. Is this correct or not?

Jumping around code.

Can we look at the philosophy and the technical aspects of the go to statement that seems so convenient, but it's supposed to be programming.

Certainly back in the day in basic programming languages, you didn't have proper loops.

You didn't have four wiles 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 go tos.

And as you made what were big programs back then, which were a thousand line basic program is a really big program.

They did tend to sort of degenerate into madness.

You didn't have good editors or code exploration tools.

So you would wind up fixing things in one place at a little patch.

And there's reasons why structured programming generally helps understanding.

But go tos aren't poisonous.

Sometimes they're the right thing to do.

Usually it's because there's a language feature missing like nested breaks or something where it can sometimes be better to do a go to clean up or go to error rather than having multiple flags, multiple if statements littered throughout things.

But it is rare.

If you grep through all of my code right now, I don't think any of my current code bases would actually have a go to.

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

Yeah, the infrastructure on top of like the closer you get to machine code, the more go tos you're going to see, the more of these like hacks you're going to see.

Because the set of features available to you in low level programming languages is not is limited.

So print John Carmack.

When is the first time if we could talk about love that you found love with programming?

You said like this, this is really something special.

It really was something that was one of those love at first sight things where just really from the time that I understood what a computer was even.

I mean, I remember looking through old encyclopedias at the black and white photos of the IBM mainframes at the real to real 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 going to back talk you, it wasn't going to have a different point of view.

It was going to carry out what you told it to do.

And if you had the right commands, you could make it do these pretty magical things.

And so what kind of programs did you write at first?

So beyond the print John 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 Superman comic that Radio Shack commissioned to have.

It's like Superman had lost some of his super brain and kids had to use Radio Shack TRS80 computers to do calculations for it to help him kind of complete his heroics.

And I'd find little things like that and then get a few basic books to be able to kind of work my way up.

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 learn a little bit of assembly language from and I'd have a few books on basic and some things that I could get from the libraries.

But my goals in the early days was almost always making games of various kinds.

I had 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?

I get sort of tack troll that type of thing and that can be done in the context of basic.

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.

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 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 could manage to do that in basic, but there's no way you could redraw the whole screen.

And I remember at the time just coming up with what felt like a brainstorm to me where I knew enough about the way the hardware was controlled,

where the text screen and the low resolution graphics screen were basically the same thing.

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 of things that I barely understood to put it into a graphics mode.

And I could draw graphics and then I could just do a line feed at the very bottom of the screen.

And then the system would scroll it all up using an assembly language routine that I didn't know how to write back then.

So that was like this first great hack that sort of had analogs later on in my career for a lot of different things.

So I found out that I could draw a screen.

I could do a line feed at the bottom.

We would scroll it up once.

I could draw a couple more lines of stuff at the bottom.

And that was my first way to kind of scroll the screen, which was interesting in that that played a big part later on in the id software days as well.

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

Yeah.

Where so much of until recently, game design was limited by what you could actually get the computer to do where it's easy to say, like, OK, 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.

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 of decades of the programming work that I did was largely figuring out how to do something that everybody knows how they want it to happen.

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 going to do the angry old man shaking my fist at the clouds bit where back in my day, programmers had to do real programming.

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 be able to figure out how to make your wishes happen.

Well, there's still, see, that's true.

But let me put on my old man with a fist hat and say that probably the thing that will define the future still requires you to operate at the limits of the current system.

So we'll probably talk about this. But if you talk about building the metaverse and building a VR experience that's compelling, it probably requires you to not to go to assembly or maybe not literally, but sort of spiritually to go to the limits of what the system is capable of.

And that really was why virtual reality was specifically interesting to me where it had all the ties to you could say that even back in the early days, I have some old magazine articles that's talking about.

Doom as a virtual reality experience back when just seeing anything in 3D.

So you could say that we've been trying to build those virtual experiences from the very beginning.

And in the modern era, virtual reality, especially on the mobile side of things, when it's standalone, you're basically using a cell phone chip to be able to produce these very immersive experiences.

It does require work. It's not at the level of what an old school console game programmer would have operated at where you're looking at hardware registers and you're scheduling all the DNA accesses.

But it is still definitely a different level than what a web developer or or even a PC steam game developer usually has to work at.

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

Let me ask you sort of a big question about preference.

What would you say is the best programming language, your favorite, but also the best you've seen throughout your career.

You're considered by many to be the greatest programmer ever.

I mean, it's so difficult to place that label on anyone.

But if you put it on anyone, it's you.

So let me ask you these kind of ridiculous questions of what's the best band of all time.

But in your case, what's the best programming language?

Everything has all the caveats about it.

So what I use, so nowadays, I do program a reasonable amount of Python for AIML sorts of work.

I'm not a native Python programmer.

It's something I came to very late in my career.

I understand what it's good for.

But you don't dream in Python?

I do not.

And it has some of those things where there's some amazing stats.

When you say if you just start, if you make a loop, you know, a triply nested loop and start doing operations in Python,

you can be thousands to potentially a million times slower than a proper GPU tensor operation.

And these are staggering numbers.

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

So your intuition is about inefficiencies within the Python sort of.

It keeps hitting me upside the face where it's just gotten to the point now I understand.

It's like, OK, you just can't do a loop if you care about performance in Python.

You have to figure out how you can reformat this into some big vector operation or something that's going to be done completely within a C++ library.

But the other hand is it's amazingly convenient.

And you just see stuff that people are able to cobble together by 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 template metaprogramming sorts of things.

I see a lot of train wrecks coming from some of that over abstraction.

I spent a few years really going kind of deep into the kind of historical Lisp work and Haskell and some of the functional programming sides of things.

And there is a lot of value there in the way you think about things.

And I changed a lot of the way I write my C and C++ code based on what I learned about the value that comes out of not having this random mutable state that you kind of lose track of.

Because something that many people don't really appreciate till they've been at it for a long time is that it's not the writing of the program initially.

It's the whole lifespan of the program.

And that's when it's not necessarily just how fast you wrote it or how fast it operates, but it's how can it bend and adapt as situations change.

And then the thing that I've really been learning in my time at Meta with the Oculus and VR work is it's also how well it hands off between a continuous kind of revolving door 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 C++ is a good language for handover between engineers.

Probably not the best.

And there's some really interesting aspects to this where in some cases languages that are not generally thought well of for many reasons like C is derided pretty broadly that, yes, obviously all of these security flaws that happen with the memory and unsafeness and buffer overruns and the things that you've got there.

But there is this underappreciated aspect to the language is so simple, anyone can go and 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.

I think there's some really, really well written C code.

I find it great that if I'm messing around with something an open BSD say, I mean I can be walking around in the kernel and I'm like, I understand everything that's going on here.

It's not hard for me to figure out what I need to do to make whatever change that I need to.

While you can have more significant languages like it's a downside of Lisp where I don't regret the time that I spent with Lisp.

I think that it did help my thinking about programming in some ways.

But the people that are the biggest defenders of Lisp are saying how malleable of a language it is that if you write a huge Lisp program, you've basically invented your own kind of language and structure because it's not the primitives of the language you're using very much.

It's all of the things you've built on top of that.

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, OK, 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 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 I wish that I had more opportunity for doing some work in go.

Rust is the other modern language that everybody talks about that I'm not fit past judgment on.

I've done 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.

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, I get meta, we have a lot of projects that use kind of react framework.

So you've got JavaScript here and then you have C++ for real work.

And then you may have Java interfacing with some other part of the Android system.

And those are all kind of horrible things.

And that was one thing that I remember talking with Boz at Facebook about it where like, man, I wish we could have just said we're only hiring C++ programmers.

And he just thought from the Facebook meta perspective, well, we just wouldn't be able to find enough with the thousands of programmers they've got there.

It is not necessarily a dying breed, but you can sure find a lot more Java or JavaScript programmers.

And I kind of mentioned that to Elon 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 want to use.

But right now, I guess, yeah, they're using JavaScript on a bunch of the SpaceX work for the UI side of things when you go find UI programmers, they're JavaScript programmers.

I wonder if that's because there's a lot of JavaScript programmers, because I do think that great programmers are rare.

That it's not, you know, if you just look at statistics of how many people are using different programming languages, that doesn't tell you the story of what the great programmers are using.

And so you have to really look at what you were speaking to, which is the fundamentals of a language.

What does it encourage?

How does it encourage you to think?

What kind of systems does it encourage you to build?

There's something about C++ that has elements of creativity, but forces you to be an adult about your programming.

Well, it expects you to be an adult.

It does not force you to.

So it brings out people that are willing to be creative in terms of building large systems and coming up with interesting solutions, but at the same time have the sort of the good software engineering practices that amend themselves to real world systems.

Let me ask you about this other language, JavaScript.

So if we, you know, aliens visit in thousands of years and humans are long gone, something tells me that most of the systems they find will be running JavaScript.

I kind of think that if we're living in a simulation, it's written in JavaScript.

You know, for the longest time, even still, JavaScript didn't get any respect, and yet it runs so much of the world and an increasing number of the world.

Is it possible that all everything will be written in JavaScript one day?

So the engineering under JavaScript is really pretty phenomenal.

The systems that make JavaScript run as fast as it does right now are kind of miracles of modern engineering in many ways.

It does feel like it is not an optimal language for all the things that it's being used for or an optimal distribution system to build huge apps in something like this without type systems and so on.

But I think for a lot of people, it does reasonably the necessary things.

It's still a C flavored language.

It's still a braces and semicolon language. 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 virtues and costs of garbage collection.

You will run into some people that are top notch programmers that just say, no, this is literally not a good thing.

Oh, because it makes you lazy?

Yes, that it makes you not think about things.

And I do disagree.

I think that there is so much objective data on the vulnerabilities that have happened in C and C++ programs, sometimes written by the best programmers in the world.

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 so much of programming is not the language itself, it's the infrastructure that surrounds it, all the libraries that you can get and the different ways you can deploy it, the portability that it gives you.

And JavaScript is really strong on a lot of those things where for a long time, and it still does if I look at it, the web stack about everything that has to go when you do something really trivial in JavaScript

and it shows up on a web browser to kind of x ray through that and see everything that has to happen for your one little JavaScript statement to turn into something visible in your web browser.

It's very, very disquieting, just the depth of that stack and the fact that so few people can even comprehend all of the levels that are going on there.

But it's again, I have to caution myself to not be the in the good old days old man about it because clearly there's enormous value here.

The world does run on JavaScript to a pretty good approximation there and it's not falling apart.

There's a bunch of scary stuff where you look at console logs and you just see all of these bad things that are happening, but it's still kind of limping along and nobody really notices.

But so much of my systems design and systems analysis goes around.

You should understand what the speed of light is, like what would be the best you could possibly do here.

And it sounds horrible, but in a lot of cases, you can be a thousand times off your speed of light velocity for something and it's 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 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, 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, 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 tradeoffs for the way we build certain things where you could throw away efficiency and actually get more benefits that actually matter.

That's one of my, you know, I one of the directions I was considering swerving into was nuclear energy when I was kind of like, what do I want to do next?

It was either going to be cost effective nuclear fission or artificial general intelligence. And 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 you could be a quarter of the efficiency or less. But if it wound up making your plant 10 times cheaper, that could be a radical innovation and something like that.

So there's like some of these thoughts around like direct fission energy conversion, fission fragment conversion that, you know, maybe you build something that doesn't require all the steam turbines and everything, even if it winds up being less efficient.

So that applies a lot in programming where there's always it's always good to know what you could do if you really sat down and took it 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, 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 they're 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, 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.

Well, if you look at the evolution of life on Earth as a kind of programming effort, it seems like efficiency isn't the thing that's being optimized for.

Like natural selection is very inefficient, but it kind of adapts and through the process of adaptations, building more and more complex systems that are more and more intelligent, the final result is kind of pretty interesting.

And so I think of JavaScript the same way. It's like this giant mess that, you know, things naturally die off if they don't work.

And if they become useful to people, they kind of naturally live and then you build this community, large community of people that are generating code and some code is sticky, some is not.

And nobody knows the inefficiencies or the efficiencies or the breaking points, like how reliable this code is and you kind of just run it, assume it works and then get unpleasantly surprised and then that's very kind of the evolutionary process.

So that's a really good analogy and we can go a lot of places with that where in the earliest days of programming when you had finite, you could count the bytes that you had to work on this.

You had all the kind of hackers playing code golf to be one less instruction than the other person's multiply routine to kind of get through and it was so perfectly crafted.

It was a crystal piece of artwork when you had a program because there just were not that many. You couldn't afford to be lazy in different ways.

And in many ways I see that as akin to the symbolic AI work where again, if you did not have the resources to just say, well, we're going to do billions and billions of programmable weights here.

You have to turn it down into something that is symbolic and crafted like that.

But that's definitely not the way DNA and life and biological evolution and things work.

On the one hand, it's almost humbling how little programming code is in our bodies.

We've got a couple billion base pairs and it's like this all fits on a thumb drive for years now and then our brains are even a smaller section of that.

You've got maybe 50 megabytes and this is not like Shannon Limit perfectly information dense conveyances here.

It's like these are messy codes.

They're broken up into amino acids.

A lot of them don't do important things or they do things in very awkward ways.

But it is this process of just accumulation on top of things and you need scale.

Both you need scale for the population for that to work out.

In the early days, in the 50s and 60s, the ancient era of computers where you could count when they say like when the Internet started even in the 70s, there were 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.

You can have this very much natural evolution going on where lots of things are tried, lots of things are blowing up.

Venture capitalists lose their money when a startup invested in the wrong tech stack and things completely failed or failed the scale.

But good things do come out of it and it's interesting to see the mimetic evolution of the way different things happen.

Like mentioning Hello World at the beginning.

It's funny how some little thing like that where everybody, every programmer knows Hello World now and that was a completely arbitrary sort of decision that just came out of the dominance of Unix and C and early examples of things like that.

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

Like there's a site on Stack Exchange called CodeGolf where people compete to write the shortest possible program for a particular task in all the different kinds of languages.

And it's really interesting to see folks kind of their masters of their craft really play with the limits of programming languages.

It's really beautiful to see.

And across all the different programming languages, you get to see some of these weird programming languages and mainstream ones.

The 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 it's kind of inspiring to see how much depth of possibility there is within programming languages that CodeGolf kind of tasks reveal.

Most of us, if you do any kind of programming, you kind of do boring kind of very vanilla type of code.

That's the way to build large systems, but it's nice to see that the possibility of creative genius is still within those languages.

It's laden within those languages.

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

Maybe a good modern programmer.

So I just gave a long rant slash lecture at Meta to the TPM organization.

And my biggest point was everything that we're doing really should flow from user value.

You know, all the good things that we're doing.

It's like we're not technical people.

It's like you shouldn't be taking pride just in the specific thing like CodeGolf is the sort of thing.

It's a fun puzzle game, but that really should not be a major motivator for you.

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, but instead they're choosing to use our products.

And that's where, I mean, it sounds triter corny, but I fundamentally do think that's how you make the world a better place.

If you have given more value to people than it took you and your team to create, then the world's a better place.

People have gone from something of lesser value, chosen to use your product and their life feels better for that.

And if you've produced that economically, that's a really good thing.

On the other hand, if you spent ridiculous amounts of money, you've just kind of shoveled a lot of cash into a woodchipper there

and you should maybe not feel so good about what you're doing.

So being proud about a specific architecture or a specific technology or a specific code sequence that you've done,

it's great to get a little smile, like a tiny little dopamine hit for that.

But the top level metric should be that you're building things of value.

Now, you can get into the argument about 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, the moment of delight when something happened,

there's a value that's happened there.

I mean, 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.

We've improved things.

So being a servant to the user is your job when you're a developer.

You want to be producing something that other people are going to find valuable.

And if you are technically inclined, then finding the right levers to be able to pull,

to be able to make a design that's going to produce the most value for the least amount of effort.

There's a ratio there where it's a problem at the big tech companies, whether it's MetaGoogle,

Apple, Microsoft, Amazon, companies that have almost infinite money.

I mean, I know their CFO will complain that it's not infinite money,

but for most developer standpoints, it really does feel like it.

And it's almost counterintuitive that if you're working hard as a developer on something,

there's always this thought, if only I had more resources, more people, more RAM, more megahertz,

then my product will be better.

And that sense that at certain points, it's certainly true that if you are really hamstrung by this,

removing an obstacle will make a better product, make more value.

But if you're not making your core design decisions in this fiercely competitive way

where you're saying feature A or feature B, you can't just say, let's do both,

because then you're not making a value judgment about them.

You're just saying, well, they both seem good.

I don't want to necessarily have to pick out which one is better or how much better

and tell team B that, sorry, we're not going to do this because A is more important.

But that notion of always having to really critically value what you're doing,

your time, the resources you expend, even the opportunity cost of doing something else,

that's super important.

Well, let me ask you about the big debates that you're mentioning of how to measure value.

Is it possible to measure it kind of numerically,

or can you do the sort of Johnny Ive, the designer route of imagining

sort of somebody using a thing and imagining a smile on their face,

imagining the experience of love and joy that you have when you use the thing.

That's from a design perspective.

Or if you're building more like a lower level thing for Linux,

you imagine a developer that might come across this and use it and become happy

and better off because of it.

So where do you land on those things?

I imagine like Meta and Google will probably try to measure the thing.

It's like you try to optimize engagement or something.

Let's measure engagement.

I admire the designer ethic of think of a future that's immeasurable

and you try to make somebody in that future that's different from today happy.

So I do usually favor if you can get any kind of a metric that's good by all means

listen to the data, but you can go too far there where we've had problems where

it's like, hey, we had a performance regression because our fancy new telemetry system

is doing a bazillion file rights 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.

For actual users using the thing, human beings using the thing,

large number of human beings, and you get to see sort of all the large numbers.

So there's 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,

like on your desktop replacement or communicating with people in different ways

or playing the games, there are going to be probably millions of people,

or at least if you pick some tiny niche that we're not in right now,

there's still going to 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 make an Alice Bob Charlie that fits whatever matrix of tendencies

that you want to 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 on the other hand, there is value to having a kind of wholeness of vision for a product.

And companies like Meta have, you know, they understand the tradeoffs

where you can have a company like SpaceX or, you know, Apple and the Steve Jobs era

where you have a very powerful leading personality that I, you know,

that can micromanage at a very low level and can say it's like,

no, that handle needs to be different or that icon needs to 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 horror stories to tell about

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

and they can have an informed opinion about everything that's going on.

And you take somebody, you've got to believe that somebody that has 30, 40 years of experience,

you would hope that they've got wisdom that the just out of boot camp person

contributing doesn't have and that if they're like, well, that's wrong there,

you probably shouldn't do it that way or even just don't do it that way, do it another way.

So there's value there, but it can't go beyond a certain level.

I mean, I have Steve Jobs stories of him saying things that are just wrong

right in front of me about technical things because he was not operating at that level.

But when it does work and you do get that kind of passionate leader

that's thinking about the entire product and just really deeply cares about

not letting anything slip through the cracks, I think that's got a lot of value.

But the other side of that is the people saying that, well,

we want to have these independent teams that are bubbling up the ideas

because it's almost anti capitalist or anti free market to say it's like,

I want my great leader to go ahead and dictate all these points there

where clearly free markets bring up things that you don't expect.

Like in VR, we saw a bunch of things like it didn't turn out at all

the way the early people thought were going to be the key applications

and things that would not have been approved by the dark cabal

making the decisions about what gets into the store

turn out in some cases be extremely successful.

So I definitely kind of wanted to be there as a point where I did make a pitch.

It's like, hey, make me VR dictator and I'll go in and get shit done.

And that's just, it's not in the culture at Metta.

They understand the trade offs and that's just not the way,

that's not the company that they want, the team that they want to do.

It's fascinating because VR and we'll talk about it more.

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.

Let me know when you want to get into that.

Hold on a second.

Stick to the you being the best programmer ever.

Okay, in the early days when you didn't have adult responsibilities

of leading teams and all that kind of stuff

and you can focus on just being a programmer,

what did the productive day in the life of John Carmack look like?

How many hours of the keyboard? How much sleep?

What was the source of calories that fueled the brain?

What was it like? What time did you wake up?

So I was able to be remarkably consistent about

what was good working conditions for me for a very long time.

I was never one of the programmers 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.

But the hard work is really important

and I would work for decades.

I would work 60 hours a week.

I would work a 10 hour day, 6 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,

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 kind of pulling in at 2 or 3 in the afternoon sometimes

and then working again past midnight or 2 in the morning.

And that was when it was just me trying to make things happen.

And I was usually isolated off in my office.

People generally didn't bother me much at it

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.

So kids were the forcing function that got you to wake up at the same time?

It's not clear to me that there was much of a difference

in the productivity with that where I kind of 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 in the morning

and trying to shift things around.

I'm often doing experiments with myself about

what should I be doing to be more productive.

And one of the things that I did realize was happening in recent months

where I would go for a walk or a run.

I cover like four miles a day

and I would usually do that just as the sun's going down 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 hold in my day

where I would have still a couple of hours after that

and sometimes my best hours were at night

and I'd be like, I don't know what else is around.

Nobody's bothering me,

but that hole in the day was a problem.

So just a couple of weeks ago,

I made the change to go ahead and say,

all right, I'm going to get up a little earlier.

I'm going to 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 work efforts,

but it's always been...

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 would have a lot of programmers

that would do these marathon sessions.

And I had Dave Taylor, one of the guys that he had.

He would be one of those people

that would fall asleep under his desk sometimes

and all the kind of classic hacker tropes about things.

And a part of me was always a little bothered

that that wasn't me,

that I wouldn't go program 20 hours straight

because 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 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, you know,

you can work 100 hours a week

and people get eight hours of sleep

if you just kind of prioritize things correctly.

But I do believe in working hard, working a lot.

There was a comment that Game Dev made

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 were really in it,

you're doing what you think is important,

what you're passionate about,

what your work gets more done.

And it's just really not possible to argue with that

if you've been around the people

that work with that level of intensity and just say,

it's like, no, they should just stop.

And we had, I kind of 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 are less productive

if you work more than 40 hours a week.

You're not really misinterpreting things

where your marginal productivity for an hour after eight hours

is less than in one of your peak hours,

but you're not literally getting less done.

There is a point where you start breaking things

and getting worse behavior and everything out of it

where you're literally going backwards,

but it's not at eight or 10 or 12 hours.

And the fictional example I would use was,

imagine there's an asteroid coming to crash into Earth,

destroy all of human life.

Do you want Elon Musk or the people working at SpaceX

that are building the interceptor

that's going to deflect the asteroid?

Do you want them to clock out at five

because, damn it, they're just going to do worse work

if they work another couple hours?

And 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 the truth.

Working longer gets more done.

So that's kind of the layer one,

but I'd like to also say that,

at least I believe, depending on the person,

depending on the task,

working more and harder

will make you better 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 the hard work isn't just about the raw hours of productivity.

It's the thing it does to you

in the weeks and months after, too.

You're tempering yourself in some ways.

And I think, you know, it's like the Girodreams of sushi.

If you really dedicate yourself completely to making the sushi,

like really putting in the long hours,

day after day after day,

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

to do with that time?

But if you're talking about purely being 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.

Yeah, and I don't gain say 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,

if you want to be stronger and harder,

is the path to getting it accomplished?

Well, let me ask you about this then.

The mythical work life balance.

For an engineer, it seems like that's one of the professions

for a programmer where working hard

does lead to greater productivity in it.

But it also raises the question of sort of personal relationships

that kind of stop family.

How are you able to find work life balance?

Is there advice you can give maybe even outside yourself?

Have you been able to arrive at any wisdom on this part

in your years of life?

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 can tell enough that I'm different

than a typical average person in the way things impact me.

The things that I want to do, my goals are different

and sort of the levers to impact things are different.

I have literally never felt burnout

and I know there's lots of brilliant smart people

that do world leading work that get burned out

and it's never hit me.

I've never been at a point where I'm like,

I just don't care about this.

I don't want to do this anymore.

I've always had the flexibility to work on lots of interesting things.

I can always just turn my gaze to something else

and have a great time working on that.

So much of the ability to actually work hard

is the ability to have multiple things to choose from

and to use your time on the most appropriate thing.

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 hard about it.

Then there's a time that maybe I should just scan

and organize my old notes because I'm just not on top of things.

Then there's the time that, all right, let's go bang out

a few hundred lines of code for something.

So switching between them has been real valuable.

So you always have kind of joined your heart

for all the things you're doing

and that is the kind of work life balance

as a first sort of step.

So you're always happy.

Yeah, I mean, a lot of people would say

that often I look like kind of a grim person

with just sitting there with a neutral expression

or even like knitted brows and a frown on my face

as I'm staring at something.

That's what happiness looks like for you.

Yeah, it's kind of true.

It's like, okay, I'm pushing through this.

I'm making progress here.

I know that doesn't work for everyone.

I know it doesn't work for most people,

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 even try that out

as an option where work life 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 obsession can often get things done

that just practical, prudent, pedestrian work won't

or at least won't for a very long time.

There's legends of your nutritional intake

in the early days.

What can you say about being a programmer as a kind of athlete?

So what was the nutrition that fueled it?

I have never been that great on really paying attention to it

where I'm good enough that I don't eat a lot.

I've never been like a big, heavy guy,

but it was interesting where one of the things

that I can remember being an unhappy teenager

not having enough money and one of the things

that bothered me about not having enough money

is I couldn't buy pizza whenever I wanted to.

So I got rich and then I bought a whole lot of pizza.

That was defining.

That's what being rich felt like.

There was a lot of little things.

I could buy all the pizza and comic books and video games

that I wanted to.

It really didn't take that much,

but the pizza was one of those things.

It's absolutely true that for a long time

it did software.

I had a pizza delivered every single day.

The delivery guy knew me by name.

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.

I was using this six year old price for the pizzas

that they were still kind of sending my way every day.

So you were doing eating once a day?

It would be spread out.

You have a few pieces of pizza.

You have some more later on

and I'd maybe have something at home.

One of the nice things at Facebook Meta

is they feed you quite well.

You get a different, I guess now it's door dash

sorts of things delivered,

but they take care of making sure

that everybody does get well fed.

I probably had better food those six years

that I was working in the Meta office there

than I used to before,

but it's worked out okay for me.

My health has always been good.

I get a pretty good amount of exercise

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.

Did you have a kind of, I don't know,

spiritual experience with food or coffee

or any of that kind of stuff?

I mean, the programming experience with music

or like I listen to brown noise on a program

or like creating 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 program.

Did you have that relationship with pizza or?

It would really be with Diet Coke.

There still is that sense of, you know,

drop the can down, crack open the can of Diet Coke.

All right, now I mean business.

We're getting to work here.

Still to this day?

Yeah.

Is Diet Coke a still partner?

Yeah, probably eight or nine a day.

Nice.

Okay, what about your setup?

How many screens, what kind of keyboard

is there something interesting?

What kind of IDE?

Emax Vim or something modern?

Linux, what operating system laptop

or any interesting thing that brings you joy?

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,

the Silicon Valley venture, you know,

culture for things.

They're different groups

and they have pretty different mores

and the way they think about things where,

and I still do think a lot of the big companies

can learn things from the hardcore

game development side of things

where it still boggles my mind 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.

Oh, that's interesting.

Sorry, so you're saying like big companies

at Google and Meta are hostile to?

They are not big on debuggers and IDEs.

So much of it is like Emacs BIM for things

and we just assume that debuggers

don't work most of the time for the systems

and a lot of this comes from a sort of Linux bias

on a lot of things where I did come up

through the personal computers

and then the DOS and then Windows

and it was Borland Tools and then Visual Studio and.

Do you appreciate the buggers?

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.

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

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 bare skins.

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 compile run debug cycle,

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 as 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 GDP

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 GDP

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 into the debugger anyways

before they even knew there was a problem

and you would just stop and see what was happening

and sometimes you could fix things

even before you did one compile cycle.

You could be in the debugger and you could say,

well, I'm just going to change this right here.

And yep, that did the job and fix it and go on.

And for people that don't know,

GDP is a popular Linux debugger

primarily for C++.

They handle most of the languages,

but it's based on C

as the original Unix heritage.

And it's kind of like command line.

It doesn't allow for clean visualizations

and you're exactly right.

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 codes if defined 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 understand the code deeper.

Yeah, when I'm working on like my C++ code,

I'm always running it from the debugger.

You know, just I type in the code.

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

of all those things there.

And I've written brand new code.

I want to step in there and I'm going to single step

through that examine lots of things

and see if it's actually doing what I expected it to.

It is a kind of companion, the debugger.

Like you're now coding in an interactive way

with another being.

The debugger is a kind of dumb being,

but it's a reliable being.

That is an interesting question

of what role does AI play in that kind of,

with Codex and these kind of

ability to generate code.

You might start having tools

that understand the code

in interesting deep ways

that can work with you.

There's a whole spectrum there

from static code analyzers

and various kind of dynamic tools

there up to AI

that can conceivably grok these programs

that literally no human can understand.

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 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

and not too many people get an opportunity

like this to have. This is almost one of those spiritual

experiences as a programmer and

awakening to the

software code bases were a couple 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

most robust, strongest code,

where there were some great things that

I remember hearing from Microsoft

telling us about crashes on Xbox

and we had this tiny number that they said

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

a copy paste, not changing something right

here, lots of things that were

the most common problem

was something in a printf

format string that was the wrong data

type that could cause crashes there

and you really want the warnings for

things like that and 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 stuff 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, you know, this

mind sitting there waiting for us to step

on and

it was humbling, it was, and

I reached the conclusion that

anything that can be syntactically

allowed in your language

if it's going to show up

eventually in a large enough code base

you're not going to, good intentions

aren't going to keep it from happening,

you need automated tools and guard

rails for things and those start with

static types or even

type hints in the more dynamic languages

but the people that

rebel against that, that basically

say, 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 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 it's going to have other people

working on it and it's going to 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 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's going to be a statistical

regularity of things that you just make mistakes

on and

I do think there's a 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

Yeah, in my private code

I have asserts everywhere

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

in too many times

I've

made mistakes

that shouldn't have been made

and I would assume

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

really helps all the time

so my

I would say like 10 to 20% of my private code

just for personal use is probably

asserts. And they're active comments

and it's one of those things that in theory

they don't make any difference to the program

and if it was all operating the way

you expected it would be then

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 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

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

and it seemed like

a good idea well we should just make this completely

you 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

and if you've got a continuously

growing collection you're never going to find out

you might have this quadratic

slowdown on something where

you thought oh I'm only ever going to 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 kind of like in many cases

picking a number

some you know nice brown 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

yeah this code was originally written

with this kind of world view

with this kind of set of constraints

thinking of the world in this way

if something breaks that means

you got to rethink the initial stuff

and it's nice for it to

for it to do that

is there any stuff like keyboard

or monitors

I'm fairly pedestrian on

a lot of that where I did move

to triple monitors like in the last

several years ago I had been dual monitor

for a very long time and

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 pure win I've been very happy

with that

but no I don't have fancy keyboard

or mouse or anything

the key things is an IDE that has

helpful debuggers

has helpful tools so it's not

the Emacs Vimrao and then Diet Coke

yeah so I did spend

one of my week long retreats

where I'm like okay I'm going to make myself

use

it was actually classic VI which I know people will say

you should never have done that you should have just used Vim

directly but

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 used Anki to like teach myself

the different little key combinations

for things like that and in the end it was just like

alright this was kind of like

my Civil War reenactment phase

it's like I'm going out there doing it like they used to

in the old days and it was kind of fun

in that regard so many people right now

they're screaming

as they're listening to this

so again the out is that this was not modern Vim

but still

yes I was very happy to get back to

my visual studio at the end

yeah I'm actually I struggle with this a lot

because

so you said Kinesis keyboard and

I use Emacs primarily

and I feel like

I can exactly as you said

I can understand the code I can navigate

the code there's a lot of stuff you can build

within Emacs with using Lisp

you can customize a lot of things for yourself

to help you

introspect the code like to help you

understand the code and visualize different aspects

of the code you can even run debuggers

but it's work

and the world moves past you

and the better and better ideas are constantly

being built and that

puts a kind of

I need to take the same kind of

treat as you're talking about but now

I'm still fighting the Civil War

I need to kind of move into the 21st century

and it does seem like the world is

or a large chunk of the world is moving

towards visual studio code which is

kind of interesting to me against the

JavaScript ecosystem on the one hand

and IDs 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 I'm 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

you know 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 are things that

we've lost with that incredible flexibility

but

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 codes maybe you know

not so bad I am

that may be the final peacekeeping solution

where everybody is reasonably

happy with something like that

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

back in the early early days

of id software one of

our big things that was unique with what we did

is I had adopted

next stations or kind of next step

systems from I Steve Jobs

is out in the

out in the woods away from Apple company

and

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 immersed in that

in college and

you know and that's you know that

sets a lot of cultural expectations for them

and I didn't have any of that

but I knew that

my background was I was a huge Apple

to fanboy I was always

a little suspicious of the Mac I was

not really what I what kind

of I wanted to go with

but when Steve Jobs left

Apple and started next 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 work stations 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

Objective C as the kind of

an interesting

next was Unix based

it's at Objective C so it has a lot of the

elements that became Mac I mean

the kind of reverse acquisition of Apple

by next where that took over

and became what what the modern Mac

system and defined some of the developer

like

the tools and the whole community

and you've still got if you're programming

on Apple stuff now there's still all these

NS somethings which was originally

Next Step Objects of different kinds of things

but one of the aspects

of those Unix systems

was they had this notion of

a dot plan file where

a dot file is an invisible

file usually in your

home directory or something and there was a trivial

server running on most Unix systems

at the time that

when somebody ran a trivial

little command called finger you could

do a 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 dot plan file

in that user's home directory and then just

spit it out to you and originally

the idea was that could be

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

to the terminal of whoever issued

the finger command

and at one point

I started just keeping 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

syntax I kind of got to myself about

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

started off as being just like my to do

list and it would be these

trivial obscure little things like

I fixed something

with collision detection code

made 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

little notes of

thoughts and insights and then I would

eventually start having little essays I would

sometimes dump into the dot plan 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 were interested in this

so most of the people didn't have Unix workstation

so there were the websites back in

the day that would follow the doom and quake development

that 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

a premonition of sort of the

way things would go and there

was 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 what

I was doing in the different areas

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

that

there's some good stuff on both where

a lot of it was low level

nitpicky details about game dev

and

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 Doomquake that's like oh clearly

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 monster behaviors

or managed resources

do you see the flaws in your thinking now

looking back

I mean sometimes I'll get the

you know I'll look at it and say yeah I had a pretty

clear view of I was doing good work

there and I haven't

really hit the point where

there was another programmer Graham Divine

who was he had worked at id and

seventh guest and he made

some comment one time where he said he looked back at some

of his old notes he was like wow I

was really smart back then

and I don't hit

that so much where I mean I look at it

and I always know that yeah

there's all the you know with aging you get

certain changes in how you

you're able to work problems but all of the

problems that I've worked I

I'm you know I'm sure that I could do

a better job on all of them

so you can still step right in if you could travel

back in time and talk to that guy

you would teach him a few things yeah absolutely

it's awesome

I'm what about the high level

philosophical stuff is there some insights

that stand out do you remember

there's things that

there's understanding about

development and I

you know in the industry and so on that

were in a more primitive

stage where

I am I definitely learned

a lot more in the later years

about business and organization

and team structure

there were

I mean there were definitely things that I was

not the best person

or even a very good person about managing

like how a team should

internally how people should work together

I was just I

you know I just

get out of my way and let me work on the code

and do this and more and more

I've learned how

in the larger scheme of things

how but sometimes relatively

unimportant some of those things are where it is

this user value generation

that's the the overarching

importance for all of that and I

I didn't necessarily have my eye on that

ball correctly through a lot of my

you know my earlier years

and there's things that

you know I could have I could have gotten more

out of people handling things in different ways

I am you know I could have made

you know in some ways more

successful products by following things

in different ways there's mistakes that we

made that we couldn't really have

known how things would have worked out but

it was interesting to see in later years companies

like Activision showing that hey you really

can just do the same game

make it better every year and you can

look at that from a negative standpoint

and say it's like oh that's just being derivative

and all that but if you step back again

and say it's like no are the people buying it

still enjoying it are they enjoying it more

than what they might have bought otherwise

and you can say no that's that's actually

a great value creation

engine to do that if you're in a position

where you can I you know

don't be forced into reinventing

everything just because you think that you need

to I am

you know lots of things about

business and team stuff that could be done

better but the technical work the kind

of technical visionary type stuff

that I laid out I still

feel pretty good about there are some

classic old ones about my defending

of OpenGL versus D3D

which turned out

to be one of the more probably

important momentous things there where

it never it was always

a rearguard action on Windows

where Microsoft was just not going

to let that win but when I look

back on it now

that fight to keep OpenGL relevant

for a number of years there

meant that OpenGL was there

when mobile started happening

and OpenGL ES was the thing that

drove all of the acceleration

of the mobile industry

and it's really only in the last few years

as Apple's moved to metal and some

of the other companies have moved to Vulcan

that that's moved away

but really stepping back

and looking at it's like yeah I sold

millions of games for different things

but billions

and billions of devices wound

up with an appropriate

capable graphics API

do in no small part

to me thinking that that was really important

that we not just

give up and use Microsoft's

at that

time really terrible API

the thing about Microsoft is the APIs don't stay

terrible they were terrible at the start

but a few versions on

they were actually quite good and there was a completely

fair argument to be made that

by the time DX9 was out

it was probably a better programming environment

than OpenGL but it was still

a wonderful good thing

that we had an open standard that could

show up on Linux and Android

iOS and eventually WebGL

still to this day so

that was one

that would be on my greatest hits list of things

that I kind of pushed with. In terms of impact it had

on billions of devices yes

so let's talk about it

can you tell the origin story of id software

again

one of the greatest game developer

companies ever it created

Wolfstein 3D games that

define my life also

in many ways as a thing

that made me realize what computers are capable of

in terms of graphics in terms of

performance it just

unlocked something deep

in me in understanding

what these machines are all about as games can do that

so Wolfstein 3D, Doom, Quake

and just all the

incredible engineering innovation that went into that

so how did it all

start? So I'll caveat up

front that I usually don't

consider myself the historian

of the software side of things

I usually do

kind of point people at John Romero

for stories about the early days

where

I've never been like I've commented

that I'm a remarkably unsentimental person

in some ways where I don't really

spend a lot of time unless I'm explicitly

prodded to go back and think about

the early days of things and

I didn't

necessarily make the effort to

archive everything exactly in my brain

and the more that I work on machine learning

and AI and the aspects of memory

and how when you go back and polish certain

things it's not necessarily exactly

the way it happened but

having said all of that from

my view the way everything

happened that led up to that was

after I was

an adult kind of taking

a few college classes deciding to drop

out I was doing

I was hard scrabble contract

programming work really struggling to

kind of keep groceries and pay my rent

and things and the company

that I was doing the most work for was

a company called Soft Disk Publishing

which had the

Sounds Bizarre Now business model

of monthly subscription software

you know before there was an internet

that people could connect to and get software

you would pay

a certain amount and every month they would send

you a disk that had some random software

on it and people that were into

computers thought this was kind of cool and they had

different ones for the Apple 2

the 2GS the PC the Mac

the Amiga

lots of different things here so quirky little

business but I was doing a lot

of contract programming for them where I'd

write tiny little games and sell them

for $300

$500 and one of the things

that I was doing again to keep

my head above water here was

I decided that I could make

one program and I could

port it to multiple systems

so I would write a game like

dark designs or catacombs and

I would develop it on the Apple 2

the 2GS and the IBM PC

which apparently

was the thing that really kind

of piqued the attention of the

people working down there like Jay Wilbur

was my primary editor and Tom Hall

was a secondary editor

and they kept asking me it's like hey

you should come down and work for us here

and I

pushed it off a couple times because I was

really enjoying my freedom of kind of being

off on my own even if I was barely

getting by I loved it I was

doing nothing but programming all day

but I did have enough

close scrapes with like damn I'm just

really out of money that maybe I should

get an actual job

rather than contracting these kind of one at

a time things and Jay Wilbur

was great he was like fedexing me the checks

when I would need them to kind

of get over whatever hump I was at

so I took the

I finally took them up on their offer to come

down to Shreveport, Louisiana

I was in Kansas City at the time

drove down

to through the Ozarks and everything