Casey Muratori: Surprises In Computer History And Where Bad Code Comes From

29:14Casey Muratori:Pascal comes later, I think. But either way, he's like, hey, I'm this important guy. I'm just going to put this whatever I want. Because they said that's not how it worked. And so he decides that in order to get it published more quickly, he's just going to publish it as a letter to the editor. Because then there's no process. Like, anything goes there as long as the editors are fine with the content, I assume. Like, it doesn't have to be refereed. It doesn't have to have any kind of review. It doesn't have to, et cetera, et cetera. So he turns it into a letter to the editor. and he takes the name of the thing that Dykstra sent, which was a case against the go-to statement.

29:47Casey Muratori:That was what Dykstra wrote at the top of the thing as the title. He changes it for a letter to the editor to Esger Dykstra colon, go-to statement considered harmful, right? So it wasn't even Dykstra's plan to like have it maybe be that confrontational, but that's what happens um now this is not well received to say the least uh the according to knuth uh again i'm just trying to say who said what here according to knuth dykstra said he got letters like like angry like threatening letters like uh in much the same way you would today right like got got people who were uh very abusive and you know telling him off and I'm sure part of that is because by all accounts Dykstra himself was also somebody who liked to push people's buttons that's well acknowledged um I think Alan Kay is probably the best source for this he talks about uh this uh he liked Dykstra and they apparently got along well but you know he he's often said that Dykstra was someone who kind of leaned into the being uh sort of brash about stating things about programming and uh and kind of relished that position so it probably didn't help that he was already sort of known a little bit in that way but in general that's that's how it went down and like i said that wasn't the initial foray against go to statements by any stretch of the imagination but it it just kind of maybe you call it the straw that broke the camel's back it was like a it was like a flashpoint might be the way to say it.

31:33Casey Muratori:And then the title, of course, that Nicholas Wirth picked is quite the doozy and kind of click baited everyone, as I call it, into that. It's funny, yeah, because I mean, your social media, it's similar patterns, right? People have very explosive first lines and then the comments are full of all this hate and stuff. In their case, I'm guessing this is all papers. so you submit a letter to that it's a physical thing and people are reading uh maybe a newspaper so i don't know yeah it's like a periodical like it comes you know as a bound i mean i guess there's all the things around us here are hard bound but it's like usually was soft it was a maybe a perfect binding uh kind of bound thing that has you open it up table of contents and letters to the editor right and uh yeah like you can go find there there are a few if you go look at people's personal papers which like like i said if i did this full time i'm sure i could find out way more stuff than i did right but some people have gone look at the personal papers and occasionally some of them have been able to digitize some of those and put them online that we can look at and you can find for example online right now if you search for it uh there's a there's a back and forth letters but personal letters between dykstra and a guy who was kind of into functional programming and promoting that and like you can look at the correspondence and it's kind of it's a little it's a little flame worry like like it it really like that's what they did they they didn't have the ability to do like pithy Twitter replies.

33:11Casey Muratori:So it was just on paper. Uh, and yeah, and Knuth did something similar. It wasn't really a flame because he had a, uh, at least when reading it comes through as a tremendous amount of respect for the authors of the book structured programming, which is, uh, Dykstra, Hoare, and Dahl. Um, he, you know, one of the things that he published was a series of open letters to them, reviewing the book and talking about the things that he didn't find compelling in it right like very respectful so it wasn't that one wasn't a flame war but that's what they yeah that's what they had to do because they didn't have social media so you know edgar dykstra he wrote like all these things called ewd with a number it was it was his initials basically um and then a number and that's like this like serialized list of all the things he wrote and he like labels them this way like it's not like some historian character after the fact it's like oh i'm doing he's like i'm doing ewd 937 now or whatever right it's hilarious uh but anyway several of those have been put online that are not necessarily technical like for example his trip reports you can go read those and you can read about like oh like i went and i went and stayed at like such and such's house and like we went to dinner or whatever right so you can find like some nice personal anecdotes in even the publicly available stuff but in terms of like a real like heart to heart conversation i didn't have access to anything like that that wouldn't have just been in a paper more or less normally um so you know that's it's a shame one of the problems with this stuff is so interesting but it's not a job to do like it's like if somehow it was a job i probably would almost take that job like like being the person who crawls through and tries to like redocument this whole thing but you know computer historian no one's no one's higher ranking.

35:06Casey Muratori:Like that's not, no one's interested in paying for that. So you have this other talk and the title was just so catching. It was the big oops anatomy of a 35 year mistake. Yes. What is that 35 year mistake? Um, so this was a, this was a kind of funny thing that happened to me that I then did a historical lecture on. I had worked on systems in the past that were basically like editors. Like, you know, you have to, like 3D graphics editors, like get the multi select things and move them around. And there's a bunch of like architecture things you have to learn to be able to write that kind of code and certain kinds of problems you have to solve.

35:49Casey Muratori:Like a very basic one that I would point out that hopefully most people can relate to would be if I have a bunch of things on the screen, some of which have a color. So maybe this is a drawing program and I've got some text and I've got some shapes and I've got some strokes, some hand-drawn stuff, whatever. And I want to be able to select a bunch of them and I want the user interface to present to me which things I could edit on these shapes. So I want to be able to edit the color and I want it to apply to all of them, right? This is just a basic architecture problem that you have to solve. If you're going to write one of these programs and you want it to be any good.

36:26Casey Muratori:Now, oftentimes you will see programs where the person didn't solve this problem and you can't do that. It's very frustrating, right? So a good program, someone has solved that architectural problem in some way. And I was watching, um, I just happened to be watching because sometimes I do like, I like to watch old videos of computer science pioneer stuff. And I was watching a demo of sketchpad. I'd seen it before, but I was watching a demo of Ivan Sutherland sketchpad and And Sketchpad, for those who don't know, is a groundbreaking computer graphics program. It's done with a light pen. And it was done in the early 60s.

37:02Casey Muratori:And you could draw things like you do in a modern CAD program. And you could do stuff that even a lot of modern CAD programs don't really offer or only offered recently. I think in the talk, I said in 2007 was the first time that AutoCAD got some of these features. you could do stuff like say these two shapes like this line has to be perpendicular to that line constrain it and you could just do whatever you want to the drawing and it would like resolve for like making that happen and these are very rare in programs even to this day like that's just not a common operation you would see in a drawing package today so i was looking at this and i was like how the heck did he solve this architectural problem like how did he do this stuff in the early 1960s, like in assembly language with no editing tools, no debugging tools.

37:56Casey Muratori:I mean, this would have been like, you know, either punch cards or one step away from punch cards. Like it would have been hard to develop this stuff. And when I went back and I went through his thesis and I looked at the code, it's actually documented how he did it. And I I realized like, oh crap, this is actually like an entity component system, basically. Like what we would now consider sort of state of the art of real time architecture for doing these kinds of operations, meaning cross cutting, like operating on this kind of property across many things at once that are all kind of different.

38:39Casey Muratori:And this was something that object oriented programming, I'm editorializing now. A bunch of people will complain that I'm saying this, but this is just my opinion. Object-oriented programming and the pedagogy around it really struggled with that problem for a long time because they were teaching, despite people who will now claim otherwise, I document it very completely in the talk. So I don't think they have any leg to stand on, but the pedagogy at the time was all about build a domain model. The domain model looks like your hierarchy, basically. Like I've got employees and employees, I've got contractors and I've got derived, like, is this a full-time employee or a part-time employee?

39:15Casey Muratori:Like that was how they suggested these things should be implemented. Right. And that kind of architecture doesn't work for these kinds of operations that I'm talking about. Identity component systems do. And generally that kind of sort of, uh, rotated architecture, I might call it, does work for these. And so what I call the 35-year mistake is the fact that very ironically, in my opinion, Sketchpad sort of showed in its architecture how you could solve this problem and how you could solve it in arguably an object-oriented way. I think if you squint at it, a person who does object-oriented programming could easily make an argument that you could do an object-oriented version of this.

39:58Casey Muratori:You don't have to violate any particular principles to do it. It's just not the hierarchy domain model way that people were conceptualizing it through a lot of the, you know, 80s and 90s, let's say. And even unfortunately to this day, but, you know, I think a lot of object ordering programs don't do that anymore. Ironically, that was in Sketchpad. The DNA was there and we could have had it right away because Ivan Sutherland figured it out. But weirdly enough, the whole idea of this sort of inheritance hierarchy with lots of encapsulation around it grew in part out of sketchpad because like alan k looked at it and said like oh the interesting part of this is the fact that you could take a shape and not know what it was and just have this like draw circle call on it or something that was the part they took away from which is much less interesting in my opinion and not that architecturally useful in most cases.

40:55Casey Muratori:So in kind of this amusing way, Sketchpad contained, if I'm editorializing, it contained what I consider to be a good architectural idea, but the takeaway from it was a bad architectural idea, is how I would say it. And saying bad architectural idea is a little bit strong because, as I say at the talk, I think there are times when you do want to think, like a very high level, you might want to think about things in kind of the way that, you know, small talk thinks about them. So I don't want to say bad idea in the absolute sense, but bad in the way it ended up being, you know, applied, let's say.

41:29Why is the class hierarchy not work for this problem?

41:33Casey Muratori:It's pretty easy to understand, actually. So when you think through an inheritance hierarchy that's based on sort of what you see in the real world or what you're trying to model. So you say like the typical example, and it's brought up tons of times by people who wrote the OOP literature, like Bjarne Strustrip, like the small talk people, is the idea is, keeping it with a sketchpad example, I'm going to have a shape. From the shape, I'm going to derive like triangle or circle. And the encapsulation is around that thing. So a circle has a radius, but shapes don't have radiuses. Shapes don't necessarily know what that is, right?

42:14Casey Muratori:So it tends to get deferred down. And the encapsulation boundary is drawn around that sort of derived class that's like the most derived version of whatever this thing is, right? The problem is that creates a lot of headaches when now something that wants to work across a lot of shapes needs to actually do something intelligent with modifying, say, the scale of something or wanting to change its color. because it doesn't really have a way to know what's going on in these highly encapsulated things. So typically what you end up having to do in those situations is you then have to take this inherent hierarchy and kind of, in a sense, throw away the benefits of it.

42:57Casey Muratori:You end up having to make at the top all of these accessor iterator things that allow you to probe into that lower class and say, tell me all of the colors that you might be using and a name for them, right? And so in a sense, what you end up having to do when you want the architecture to work is you have to rebuild the sketchpad version on top of the inheritance hierarchy version, which doesn't really do anything for you, right? And it's not to say that there isn't some benefit that you can derive from having, derive is kind of a pun here, I guess, that you can derive from having this idea of saying, this thing is like this other thing please give me some of the implementation of it that's not necessarily a bad thing in practice the problem is when you teach people that this is how it's going to work like you just make this hierarchy and then your architecture is supposed to work it really ill prepares them for the reality that like that's actually not going to solve most of most of the problems that you have are not going to be solved that way um and again it just comes from this fact that typically when we're working with computer programs most of the time what we need to do is create cross-cutting operations that work with a lot of the data that's inside these derived classes.

44:10Casey Muratori:That's actually the thing that we want to do. And it's really cumbersome and typically a bad fit for the problem space to put that into some virtual functions that are sitting at the top of this very sort of tall hierarchy. It's usually much better to do, again, even if you're doing object-oriented programming, you don't have to stop doing object-oriented product, you just have to think about it differently. You have to think about what the objects are differently, where you're drawing the encapsulation boundaries. It just helps to think about it differently and say, actually, the more important things to model are what are the things that stuff is built out of?

44:44Casey Muratori:How do I build a circle out of objects, right? What are those things? A radius property, a center property. Those maybe should be the objects that I'm thinking of as more first-class citizens. And this inheritance hierarchy stuff about what the objects are that I see on the screen, like triangle, circle, that's a distraction. That's not the proper way to model the problem. And again, I don't think I would be pissing off any object-oriented programmers by saying that today, because I think a lot of them use architectures that do think about objects in that sort of rotated sense and not in the domain model hierarchy sense.

45:20Casey Muratori:Not that there aren't still people who are doing that, but it's not the only way to go nowadays. It's not the only way that's it's promulgated because i guess my immediate thought would have been in in that case the the base class has the notion of a color or some shared thing and we just operate if you're a shape then we assume you have a color and we did but you're saying refactoring and putting up in there's suboptimal and there's you want all these uh subclasses to have some handle to some radius property or something like that is that what you just described is what tends to happen in systems that are archited this way you end up with your derived class not really being very much of anything because in order to edit stuff you had to migrate it all up to the top and that there was actually terms for this uh in the old days i don't still use like fatty base classes right or things like that's like it just ends up your base class has like every type of property that any derived class might ever have like you have like get primary color get secondary color get tertiary color, right?

46:22Casey Muratori:Because it's like something needed three different colors or whatever. And most things don't use those colors and all these other sorts of things, right? And so there's certainly nothing wrong with running a program that way. It's just, again, why did you bother with the hierarchy? Like you're not getting any actual encapsulation benefits from it because you just forced everything to the base class anyway. So why didn't you just make that be your thing? Just make one class called shape and be done, right? So in terms of the ECS style of implementation, and I don't necessarily want to advocate for it or not, because I don't actually personally use ECSs or anything like that, but they are very common now.

47:00Casey Muratori:The idea there is to just turn it on its side and say, look, typically what we want to do is do things like, okay, there's stuff that has like physics on it. Like, you know, I'm doing this thing and I want to have like physical simulation of entities. Well, the physics system is the thing that probably knows how that should be stored. So rather than having that be data in my derived class that is encapsulated around the derived class, instead, why don't I just have the physics system knows what physics is? And then if you want to make something that participates in physics, you just have a handle for whatever this thing is, like a handle for my shape.

47:36Casey Muratori:That handle is valid in all the systems. So I can go look up the physics properties of the shape and gather it when I want to actually do something with it. But generally speaking, the encapsulation stays around the system. So physics properties are defined by the physics system because, hey, that's who knows how physics should work. And I just ask about my physics when I need to do something with it. And this kind of gets you out of that problem. And then now you can just compose things. Oh, I want to make something that has several physics elements in it. Fine. I can just have multiple physics handles if that's what I need or something like this.

48:09Casey Muratori:I can very flexibly merge these things together. I want something to not have physics. I just don't ever ask the physics system to have a valid piece of data for this handle in it, and it won't simulate any physics for it. Whether that's the world's best architecture or not, I'm not going to argue for it or against it. It's just it's a lot better than domain model hierarchies. That I will say. OpenAI, Anthropic, Cursor, and Vercel all use this product to make their lives better. And the problem it solves is when you're building SaaS or an AI product and you want to sell to other companies, there's all these requirements you need to meet.

48:49There's SSO, there's SCIM, there's RBAC, there's audit logs. These are all things that take time to integrate but aren't the main focus of your app. WorkOS is an API layer that lets you meet all of these requirements in just a few lines of code. So let's say you have a new SaaS product and you want to sell to other companies. WorkOS will solve all of these critical feature gaps for you. You can check them out at workos.com to learn more and get started. And I appreciate them for supporting my work and sponsoring this podcast. Jira by Atlassian isn't just for tracking work anymore. Now you can pick your favorite AI agent to assign tasks to, and they'll get access to the rich context that's already in Jira.

49:30When the agent is done, it surfaces a pull request. That way you can get more done with your favorite agents all in one place. Learn more at jira.dev. That's J-I-R-A dot D-E-V. Appreciate them for sponsoring the podcast. And back to the show. Earlier, we talked about the tradeoff between, I guess, performance code and maintainable code. And I saw you had this one video. said, you know, in quotes, clean code, horrible performance. I feel like this is on the same topic. What's your take there on, you know, because you also put clean code in quotes. What does that mean?

50:12Casey Muratori:So it's a fairly subtle topic, right? And that's why the quotes are there, because the first thing that you have to point out is that clean code is clean code, object-oriented programming a lot of these phrases they mean different things to different people and so if you're going to say that you're you know this code is clean it's pretty hard to find two programmers who will agree on exactly whether it is or not right like like they all have like different ideas about what is clean and what it's not right so the reason i put that in quotes is i was talking about a very specific thing which is like literally like the book clean code like the thing where there's like, here are the things that we would recommend that you do.

50:53Right.

50:54Casey Muratori:So in that particular case, what I was talking about is there's a certain set of ideas that is advocated in clean code as like, these are the things you should do. And they are like, you should have, uh, everything should be kind of, um, I guess I would say dynamic dispatch, or at least you shouldn't, code shouldn't know the types it's operating on. Right. Saying it's dynamic dispatch is maybe it depends on the language, whether that's going to be true or not. But when I write code, I don't know what types I have. It's just, I don't know, like some base classes is what I'm operating on and they could be anything, right?

51:28Casey Muratori:That's thing one. Thing two is functions should be very small. In fact, the numbers are kind of weird. They're like four lines or five lines. Like when you go look at the actual things that are claimed in some of this literature, it's really strange. You're just like, gosh, that's very small, right? And I go through some of those things and I say, look, if we were to actually follow these, we get into a really bad state because a lot of the languages that people are going to be using to implement this stuff, like C++, for example, which even would be a fairly good case in a lot of cases, at least it's a compiled language and so on.

52:05Casey Muratori:In a lot of cases, these things are kind of a recipe for disaster. If you're handing out types where you can't know the type at compile time or you can't know the type or it's gonna be in a different module. So unless you have like a really aggressive link time code generation, it's not gonna be likely that you can figure this out. And you're saying all the functions should be very small. And then of course they're gonna be virtual because they're on these sort of types that you don't know what they are. This creates a really toxic combination for the compiler. Normally you can have, I mean, you can have small functions if you want them only four lines long.

52:40Casey Muratori:If the compiler can know that it can just inline that, right? If it can see clearly what you're doing and it can just merge those things in, we don't have a problem. If they're behind a virtual function so it doesn't know, like it can't guarantee that it is that type, it can't do that. And so when you talk about all this stuff, what you're giving up, people, I think also because the video, I mean, the video was a very short video. It's part of like a series. I think people sometimes get the wrong idea that I think that virtual function calls cost a lot. They do cost something, but depending on how you want to look at it, they actually don't cost that much.

53:16Casey Muratori:Because it depends on whether it's predicted correctly or not, but in general, the cost of virtual function is less than you would think a lot of times. The actual reason that it slows things down is because the compiler cannot merge the code together. It can't inline stuff and remove and reduce the waste. That's the actual problem. So if you just want to call a virtual function, yeah, if it was a really, really hardcore optimization scenario, then you don't want anything probably calling a virtual function in general because there is some cost to that. Just calling a function has cost. But that wasn't the really bad part of it, right?

53:51Casey Muratori:So it's that. Plus, there's an additional thing, which is that it can't unroll and go wide on things. If the compiler can see everything you're doing, it can use SIMD. It can, like, widen loops to operate on multiple things at once. it can unroll those loops there's all these things it can do if it's got these virtual functions it's just like that's it i don't know i can't make decisions about that i have no idea what this thing on the other end is doing right so uh that was kind of my point on that and uh again i it's not meant to be assailing the idea that your code should be easy to read or easy to maintain it's just more like these guidelines seem really bad and also i don't think we need them for code to be maintainable.

54:29Casey Muratori:I don't have trouble maintaining functions that are 30 lines long or 50 lines long. I don't find that five is a magic number or something, or that has to be really short. And also I find that it's usually pretty easy to write code where I know what the types are, that those can be determined to compile time. I don't think that results in code that's particularly hard to read. When I was in college and very early, I remember people would recommend that book. So, oh, you should read clean code. So my understanding that you wouldn't recommend people who are software engineers to read that i guess the way i would categorize it's a mixed bag so i wouldn't i wouldn't actually say that i disagree with all all of the things in the book though i mean some of the things are things that i definitely do myself like giving um variables like easy to understand names uh is something that i think would be and that's in that book uh is good advice right and so kind of more i wouldn't i wouldn't necessarily say do or don't read a book what I would say is like I think there's some things in this book that don't that aren't addressed properly like I don't think you want to tell people these rules of thumb and not tell them about these other problems that was exactly what I was pointing out there and so usually it's more that it's like And I find that oftentimes there is this tendency, I guess I'll say to pretend that we don't have to talk about performance and we can just say like, in fact, premature opposition is the root of all evil, bringing it back to there.

56:02Casey Muratori:I feel like there's this temptation and very prevalent practice of sort of taking that idea to mean we don't have to talk about performance when we're teaching people things at all. Or like when you write the book Clean Code, you don't have to talk about performance at all. You can just include a thing that's basically like, hey, you know, there's performance issues, but most of the time it's not a problem or something like that. Or if you look at refactoring, the book Refactoring, very popular. It literally says exactly that in like the opening thing. It's like, you know, there might be performance concerns, but, you know, they're usually okay or something, right?

56:38Casey Muratori:And it's like that is not true. I just think that's fundamentally not true. I think these books should include detailed discussions of the actual performance problems that you are very likely to hit if you take some of their advice. Because it's not that it means you can't do those things, but I'll quote you back to you. It's about tradeoffs. There is always a tradeoff that you're making. And sometimes if you understand the tradeoff, you will make it. You'll say, I know this is going to cost, this may be a serious performance problem for us, but I think that's okay. Like, I think it's not like our performance won't suffer to the point where it's a problem for the product.

57:20Casey Muratori:I understand what that is. There's a huge difference between that and just going like, eh, we don't worry about performance till the end, right? Like there's, it's completely different, right? Those are two different engineering approaches. and so what I try to do is encourage people to put that analysis back in understand the performance trade-offs you're making understand how much it might cost in the future to like make these fixes and I don't really do any AI stuff but my sort of feeling is more so now than ever I feel like that's got to be pretty important because you're instructing these AIs to do what they're going to do.

57:58Casey Muratori:And I feel like it would be a bad idea to not know about performance trade-offs because especially if an AI is going to be doing your bidding and structuring the code the way you want to structure it or doing whatever, it seems like a very straightforward part of the process to include performance stuff in those instructions, right? Like that would be a natural thing that we would want to understand and do, right? So I feel like really I've been just trying to get that more into the conversation. And I feel like it's as relevant now as it ever was, and arguably maybe more so. I don't know, but I could be wrong about that.

58:33What are some things that are in your mind that are those high value performance things to consider that don't cost a whole lot to think about?

58:43Casey Muratori:So to me, awareness is the number one thing, right? Understanding roughly the performance characteristics of the hardware that you're working on, which includes things like if there's a network, like what does that look like and so on. It's really about awareness more than anything else because a little bit of awareness can go a very long way. If you understand the basic concept that network latency versus network throughput are different things, you can make upfront decisions about structuring code such that you batch things properly and so on and so forth. If you don't understand those things, you could get very far down a project only to realize that everything you designed and all the way it works is all very serial and really just cannot be accelerated over a network at all.

59:33Casey Muratori:Like it's never going to run reasonably or something like this. And so I think the lowest hanging fruit is just to get some education in performance. Like get some education in how to think about the way a machine works and what makes it fast or slow, what it struggles with and what it doesn't. And just to keep that in the back of your head. Because at the end of the day, if you have that knowledge, I think you're very unlikely to make the kinds of architectural decisions that will be hard to undo later. Right? And so that's really the majority of it, I think. and that is by far the highest impact, lowest cost thing you can do is just do that training once.

1:00:18Casey Muratori:Because once you have it, it's with you forever. Once you understand how to think about performance, it can always be there. And at any time, you can sort of have that alarm bell of like, hmm, this, I don't see, you're always kind of looking like, I don't see the path towards this running well. And then so that's your key to stop and go like, maybe we need to rethink like how we were making some of these decisions. As long as you can see that path, you can delay most optimization work. As long as you can see the path, like here is how we will optimize this, you're in pretty good shape because if you're making those trade-offs correctly, you're not going to paint yourself into a corner where there's nothing that you can do other than scrap and rewrite, right?

1:01:05You had this one video title. is it said, you know, where does bad code come from? Yeah, I guess, yeah, my question to you is, what's the answer to that? Where does bad code come from?

1:01:17Casey Muratori:Yeah, that's a good question. My feeling on where bad code comes from is that for everything that I've seen on projects in the past, the bad code all seems to come from roughly the same source. and that is not dealing with the actual thing that's happening, right? There's a lot of ideas in computer science about sort of doing upfront design and making a lot of decisions without ever really implementing anything, right? And I have found that universally that leads to the worst kind of code. And the reason for that is, you know, I hate to be pessimistic and I hate to be pessimistic about my own ability, but I'll just say for me personally, I am not able to correctly hold all of the details for most complex software in my head at once.

1:02:20Casey Muratori:there's just a lot of stuff going on at like when when the actual you know instructions hit the cpu there's a lot going on down there that's very hard to keep all in your head and so when you approach an upfront design typically unless the problem is very is like stupidly simple right when you approach something with upfront design and you think you're going to get all of this architecture worked out ahead of time, you forget some important things. You make decisions without realizing, oh, wait, there's this thing that has to happen there that means that this isn't really the right way for these pieces of code to interoperate.

1:03:02Casey Muratori:And so then you end up seeing these hilarious APIs or something where it's like, you're just like, how did this end up being the way that you do this, right? Like I have to create all these objects and I have to connect them together with these things. And I have to create this weird like filter graph thing. And then I have to call compile on it. But only like you end up with these like insane things. And you're like, all I wanted to do was call this one thing that said like low pass filter this buffer. It could have been one function call. Right. It's like, how did you get there? And the answer is because you weren't actually like dealing with the actual problem and looking at what the actual code looks like, uh, when you want to actually, uh, when you actually want to solve the problem in practice.

1:03:42Casey Muratori:And so my idea where bad code comes from is usually just, it's that it's this failure to engage with the actual reality of the situation. Um, maybe there are people out there. I certainly have never met any, but maybe there are people out there whose brains are so expansive that they can actually hold all that in there and they can therefore just do it up front. Um, but other than for various sort of constrained problem spaces, I've never seen that work. And, And, you know, like I said, there are some times when that's the case with the train disrupt. Like if you're just doing like, I'm trying to do this particular mathematical operation, that might be a case where you can work it all out on paper because it's very specific like what it is.

1:04:21Casey Muratori:It takes these N inputs, produces this output, and I can work, right? But when you're talking about architecture, like, hey, it's a web browser, right? Some complicated thing, the details are all that matter to me, right? It's like it's where all the complexity lies. And if you try to do the design without reckoning with them, it just leads to bad results in my experience. So how do you avoid writing bad code in that case? I try to start with the actual solutions to the problems and work up from there.

1:04:54Casey Muratori:So one way to say it would be instead of top-down programming, bottom-up programming, right, as much as possible. And top-down programming isn't really the same as designing up front. But, you know, I'm just saying, like, as a contrast there. try to start with the things that you know you need. Like, it's like, okay, if I'm building this thing and it's got to have a rasterizer, all right, I'm going to start making a rasterizer. I'm going to see what kinds of stuff that does and how I would, like, what's the most straightforward way to call this and use it? Okay, let's make an API out of that, right?

1:05:20Casey Muratori:Like, build it out of steps where the abstraction comes from actual working code that gets abstracted rather than pushing the abstraction down from the top where I say, this is how I will abstract the rasterizer. And now I go write the rasterizer and the thing that uses the rasterizer only to find that that is not a very good way to use a rasterizer, right? Like, so to me, starting with that and working upwards is the best way to ensure that you will get an architecture that is at least good for one thing. Now, if you want it to be good for multiple things, you probably need a couple different, like I want a few different varied things that would use this rasterizer that I will kind of work on together and I'll make abstraction decisions that work across all three of them.

1:06:07Casey Muratori:That's a good way to make a more reusable API that works for a lot of things. But I never want to just sit down and say, hmm, how will I design an API for lots of people to use a rasterizer without actually writing any of it? It's like, no, no, no. And I definitely can't do it. And I would question someone who says that they can unless, one caveat, they've written a lot of them before, right? If you've written tons before, then you've sort of done the thing that I'm talking about already. And you might remember, oh, it's this way. Right. I think there's a lot of common advice, especially at these larger companies where there's this processes to, you know, write a design doc and kind of, you know, put together everything in advance, present it before you write any code.

1:06:54And sounds like you're saying that that's a terrible idea.

1:06:57Casey Muratori:I think that's an absolutely terrible idea. Now, that doesn't mean that I wouldn't be okay with that process with like a slight modification, right? If what you're doing during that time is writing test code in the way that I'm saying, so we're going to write a little experimental rasterizer, we're going to do those things, and then our document that we're producing is here is what we have determined is a good API based on these experiments. I have no problem with that. That's really, that's following my procedure pretty much to a T. And, you know, I don't tend to produce documentation because I work, you know, in, on smaller teams.

1:07:32Casey Muratori:I don't have to have an a thousand person org know exactly what it, what I'm doing there or whatever. So I wouldn't produce upfront documentation normally in a case like that. But if you, if you wanted to, that seems totally reasonable. Right. And that like is communicating our research into how this should be structured out to a wider audience. But we still did the due diligence of determining that it really does work in practice. It's not just our guess about what it will be. I see. Okay. So you're saying kind of this pair design, pair prototype kind of, you know, like you just build as you go, but it's just so you get a sense of the reality of the design.

1:08:10Casey Muratori:Yeah. And I think I would be very comfortable with the team that wanted to work that way. They're like, look, we want to produce, we want to document this thing before we start developing it. That's just how we feel more comfortable, you know, with how we're going to do it. Maybe it's a very large org. Maybe we have some very good reasons for that. Then I would say totally fine. It's just I want, I want to hear, you know, if I'm going to be comfortable with it, I want to hear that that process is not we're just typing on paper. We are actually testing these API design decisions and they come from looking at actual usage code that we have made and that we have implemented at least experimental versions of so that we know they really do account for all the details that we're likely to encounter in practice.

1:08:53Casey Muratori:That's what I want to hear, right? I don't want to hear like, oh, we thought it through. Like, I'm like, did you? Did you think it all the way through? Because I've seen a lot of times where people thought they did and they didn't, including myself. Like that is not, that is not a, I always think it all the way. So it's like, no, this comes from a personal place of, I forgot the thing. Like I forgot this important thing and I made a really stupid design. Right. There's another video you had is titled the only unbreakable law. Oh yeah. What is the only unbreakable law in software engineering? So yeah, that was, that was a lecture I did, um, where I was trying to think of like, if I was going to say one thing about architecture to people, right?

1:09:33Casey Muratori:If I was going to say one thing about architecture, what could I say that isn't probably wrong? Because you think about a lot of our ideas about architecture, it's like even the stuff I just said to you, who knows what we're going to be thinking 10 years from now? It's like they're not really laws. They're just observations that we've had that maybe this is a good way to do things, but it's not really a law, right? so uh the only thing i've seen that feels like a real law to me is the thing i cover in this lecture which is conway's law uh and this is a a it's not a real law in the sense of like the laws of gravity or so like it's not a physics law like a physicist would laugh at calling it a law um you know it's probably not even a theory it's more like a hypothesis at this point right But in terms of things that I would place money on being validated as a law at some point, if we ever had the means to do so, this would be one of the only software engineering things that I think would qualify.

1:10:40Casey Muratori:And it is that if you would like to organize a series of like a set of people to work on something or in the modern parlance, let's say agents. So it could be it doesn't have to be a human. It's any system that has sort of its own internal processing like a human brain does or like a computer does. if you need to partition a problem into a set of workers in this way where the communication between those workers is slower than their own internal computation ability which we would all agree is true about humans it's true about two computers running an ai model as well right the amount of time it takes to send information back and forth to them is is significantly slower than what like the gpu can be processing directly on it on its own right In the systems that look like that, when you start to tackle a problem in order to get the benefits of that parallelization, you will have to make decisions about who is working on what.

1:11:43Casey Muratori:At least some decision. For example, if we are making a car and you and I are the two people who are going to make the car, I'm going to design the body of the car, you're going to design the wheels. Just a decision someone could make. once you've made that decision you have now locked in the fact that the iteration on the design will be slower across that boundary than it is interior to either of the two parts so for example your ability to improve the design of the wheels on their own and my ability to design the body of the car and improve that on its own will be much faster than our ability to design the interface between the wheels and the tire, or it's not even just the interface, the degree of harmony between the designs.

1:12:38Casey Muratori:So the degree to which your wheels complement my body design and my body design complements your wheels, that they all are considering the trade-offs together, right? And Melvin Conway's paper, which lays this out, this is a very early paper. It's, you know, it's in the 60s at least. Was it in the 50s? It's way back when. That lays this out, points out the consequence of this is that products or any, and when I say product, I mean anything that comes out of one of these design processes or development processes, products will have a similar structure to the organization that produced them. You'll be able to see in the product evidence of this because the degree to which things are able to harmonize is restricted across that boundary.

1:13:28Casey Muratori:So when you look at the object, it will have that boundary visible in some way, right? It won't be quite as good at the interface between these two things or in the way that they work together as the things are themselves to themselves, right? And it gets sort of flattened. Like one way the rule is pithily stated is like products look like the org chart, right? But that's not exactly what it says, but that's kind of a downstream consequence. And boy, do you ever see it in the real world. So, you know. I've heard that in the context of these big tech companies, almost like it's a bad thing to, quote unquote, ship your org chart or basically, the product you put out there has these inorganic things.

1:14:22It sounds similar to what you're saying.

1:14:24Casey Muratori:Yeah, and I think part of the reason I think it is kind of an unbreakable law is I think it's somewhat unavoidable. uh it's more something that you just have to be aware of and mitigate to the degree that you can like you just have to understand look that lower communication time uh whether it's humans or computers or whoever is doing this work that lower communication time uh or i should say that that lower communication bandwidth that just means that we will like where we draw these lines has consequences for what we ship. And so we really want to try over time to align those boundary drawings to places where it will have the least bad impact on the result of the product.

1:15:14Casey Muratori:And, you know, that's true for org charts. Like I said, I suspect it will also become true for AIs and things like that, where it's like, you will want to partition these problems in ways that respect that, um, that line drawing, because that will be less good than the thing that can be wholly solved, um, you know, by one, one unit, whatever that unit is. And so to me, uh, it's a very helpful construct for thinking about things. It's also a very good explanation for why you see something somewhere. You're like, why isn't this just integrated in this? It's like, because there were two different teams, you know, it's like, I'm sorry, like, I'm like, I'm sorry.

1:15:50Casey Muratori:That's just the answer. And it costs a lot more for those two teams to have integrated this. That's not how we work. I'd love to hear more about, I guess, your career and how you got into programming. I started programming when I was really little because my father worked at Digital Equipment Corporation, which is actually a very important company in that era, no longer exists. They would be sort of like almost like a case study in how not adapting to a change in technology leads to your demise. They were one of the most important companies in the world for computing. If you've ever heard of a PDP-11 or a VAX in computing history, that's them, right?

1:16:36Casey Muratori:They made these things that were foundational computers in computing history gone today, right? They were, part of them got absorbed by Intel, part of them got absorbed by Compaq, but they don't exist. so he worked for that company and so we always had computers in the home and I learned to program when I was little and that's just sort of always what I wanted to do I really enjoyed it and so I ended up uh getting an internship at Microsoft when I was pretty young and I met some people there I came out to I should say I grew up on the east coast so nowhere near Microsoft um I met some people there.

1:17:16Casey Muratori:I ended up coming out to the West coast really early on. This would be in like 95. So yeah, what didn't feel early at the time. It felt late in the computer history, but nowadays it's like, Oh wait, 95. Oh my God. Like before, before everything was on the web. Right. I ended up, there was a web though. It was, it was nascent. Um, I ended up coming out and, and working sort of in the game industry. And that's what I did ever since. And I've mostly always worked on game technology. I'm famously absolutely terrible at understanding game design. People who watch my stuff know this about me. I'm very, very bad at it.

1:17:54Casey Muratori:I've tried to make games a couple of times, and I just cannot do the design side. I'm awful at it. But I really enjoy the engine stuff, and I feel like I'm okay at it, and I've been able to contribute to projects. So in general, most of the time, if you've used code that was written by me, you probably used it in the context of like a video game that was using technology that I wrote. And so, you know, an example would be, um, I worked at rad game tools on a character animation system. Uh, I wrote the entire thing myself that is used. Well, that's not entirely true. I wrote the entire thing myself, except for the texture compressor, which Jeff Roberts wrote, there was like this texture compressor that you could use, um, as part of the pipeline for the exporting and stuff like that.

1:18:37Casey Muratori:And it was a pretty cool project at the time. Um, I'm really proud of it. The first version was awful as it is because I was pretty new at the time. The second version, I thought we did a really nice job. And it was made at a time when people didn't think you could do licensable game technology of that kind because it was too hard to integrate into things like you couldn't get the performance or whatever. And we did a lot of things that I think were pretty innovative at the time. And we were able to make something that was very successful. And it's, I mean, we released the first version of that in 99 it's still in use today largely unchanged from the architecture that i guess was the second version i did in like 2001 or something um there are a few changes to architecture that people have made over the times but it's largely unchanged and i mean like i found out recently baldur's gate 3 which was a big game um from larian came out i had no idea it turns out they still use they use it right it's in their engine or whatever so i'm very proud of that product because I think it, it was in tons of games and was a very hard problem to solve.

1:19:39Casey Muratori:And I think we solved it pretty well. It's largely irrelevant today. I would say it's still in some people's like engines over time, but like, it's not the kind of product you would make today because nowadays engines are monolithic and you license them as a whole typically, right? Like you, you wouldn't be getting like a character animation library. It's going to be something that's like built into unreal engine or built into unity right so it's not the kind of product you would probably consider making today so that that was mostly um like in terms of things that i've done that people might have actually have experienced or used uh like folks at home if you've played games you may have played something that i had a hand in at some point but only the technology not the design i also worked a little bit on the witness um which was a game by jonathan Blow and team that I thought was absolutely fantastic.

1:20:30Casey Muratori:And I did some work on the walk system there that I was pretty proud of. I thought it came out pretty well. There's some parts of it that are really janky. I don't think I did a very good job of the actual implementation of it, but the design was pretty good. Let's put it that way. Early in your career. So you worked at Microsoft and then you went to go - I was only ever an intern. I mean, I guess that's technically working there, but I didn't ever work there as like an employee. As someone who's writing code, I mean, there's a lot of different paths, but there's one path I imagine is you go and you work at one of these big tech companies and create their tech products, I guess.

1:21:09And then video gaming seems like another path. And I think there's other paths as well, of course. What drew you to going towards video gaming and not continuing down Microsoft path or something like that?

1:21:25Casey Muratori:I think that there's a bunch of things I could say about that, but they're probably all BS. The truth is probably that I'm probably more affected by the people around me than I would like to admit. I mean, I guess I don't have a problem admitting it now, but I mean, at the time, I probably wouldn't have said that right. I could envision an alternate past where I did stay at Microsoft and try to get a job there and work there instead of being just an intern and then going off and working at a different place. The reason that didn't happen was because of the people who I worked with there when I was an intern.

1:22:06Casey Muratori:I fundamentally really like, like nowadays, I fundamentally really love doing things like, you know, analyzing assembly code or looking at exactly how a microarchitecture is working and these sorts of things. If I had gone to Microsoft and had just happened to be under some people who were doing that kind of work and had like taught me how to write like device drivers in assembly language or something like that, I might still be there today. Right. that's not what happened the capsule summary is the group that i was supposed to be in the way that they did internships at that time was that a set of interns say uh three or four of them would be uh underneath a particular manager who was going to like be managing those interns so there were a couple of us who were supposed to be reporting to to this guy whose name i won't mention just in case for some reason it's ancient i probably wouldn't care at this point but We're reporting to this particular person and literally the week before we arrive, he has this massive flame out with upper management leaves, like just walks out of the building and has not been heard from since.

1:23:25Casey Muratori:So we show up and it's me. There was like me, this guy named Rudy, a guy named Rajiv. And we're just interns. We show up. We're like, hey, how's it going? And we report to this test guy, this SDET, a guy named Scott Latham, really nice guy. And we're like, we're supposed to be reporting to a software or what's going on? This is one of the guys in the test org. He's like, yeah, that guy's gone. He's out of here. right uh and and me and this other guy bruce johnson are gonna like take care of the interns because yeah right we don't really know what you're gonna do uh the first thing i think bruce bruce had me do was like an ani cursor loader there was there's this format i don't know uh ancient history now but there's this format for animated cursors on windows if you ever see the stupid little walking dinosaur or the like this is no one uses these anymore i don't think but they were this thing that was in there.

1:24:30Casey Muratori:He had me write a parser for loading ANI files, right? Like it's just meaningless stuff. So my experience there was pretty lame. Like I was like, this is kind of dumb. Like I don't really want to work here. Right. But it could have been totally different. Like if I had been on some team that had like really inspired me to like learn the stuff that I didn't know, I didn't know assembly language at that time really at all. I think the only thing I'd ever written assembly language was a joystick pulling routine for DOS because it's the only way you could pull the joystick and DOS, right? And I think that's really it.

1:25:01Casey Muratori:If I'm honest about it, I think most of it is that I think when you're, even if you're a very brash youngster, which I was, and even if you think that you're very independent, I think you definitely gravitate towards people who you see doing things you think are impressive or, you know, technologically interesting. And that is just not the experience I had at Microsoft. Now, there were some people who I, like the people I went out to go work with were people in other parts of Microsoft who were leaving Microsoft to do like a startup company. Right. And those are the people that I was really like impressed with.

1:25:37Casey Muratori:Like, those are the people that I wanted to hang out with. So like, if I just look at it in the rears, like if those people had just been staying at Microsoft and doing something, maybe I would have gone. Right. And I think that's the truth of it as best I can determine at this point. Anyway. So you moved across the country to go and work with those people at a startup, that feels pretty risky to do. It was, especially because at that time, a startup is not really what you think of as a startup today. Startup is just some scrappy people in a crappy office doing stuff. Nowadays, you think startup, it's like, well, we've got$10 million in VC funding, and we have free sodas in the break room, and a masseuse comes in periodically or something like this.

1:26:22Casey Muratori:right? Like, I don't know what the, what the now version of a startup is, but it's very different. Right. Um, so yeah, it was, it was pretty risky and I don't really know why I did it. It was mostly just because I hadn't had really good experiences with education. Like I didn't really want to, to do, um, like college or like, I didn't want to do any more education. Like I wanted to actually work for whatever reason. And this seemed like a, this was just the easiest way to do that. And I don't really regret it, honestly. I've been able to learn most of the things that I would have needed to, like if I was going to go do a PhD or something, like I've ended up doing work that I, that is the sorts of stuff.

1:27:07Casey Muratori:Like I've, I've been lucky enough to be in positions where I could go spend, you know, a few months writing like this, you know, uh, this particular like linear least squares solver or something like that, like the kinds of things you might have done as like a thesis or something, uh, or, or, you know, that, that walks us and I've done the witness, those sorts of things are the kinds of things you would have done had you decided to get a master's degree or something like that. So I'm fortunate enough that I've kind of been able to have that part of the education, um, because not everyone gets that opportunity.

1:27:41Casey Muratori:Like you may never get, you know, if you, if you don't do a master's thesis or you don't do a PhD thesis, you may never really get the chance to like really do a deep, like work on a, on one problem and like learn a lot about it, read a lot of papers, do, you know, make, maybe make some novel contribution in, in some very small way usually. Right. But, um, and so that, that I was just lucky enough to do. So I don't really regret not doing something like that but i think you know had i not had that those opportunities and subsequently i could see being i could see being regretful about that because that is something that i do enjoy doing and if i'd never had the chance i would have been sad so you and you went and you traveled to this startup because there's there's no there's no funding it sounds like so yeah what'd you it's just a group of guys just was there pay or it's just Not really.

1:28:31Casey Muratori:No, it was, it was pretty rough. Uh, and I, it didn't last very long. Right. Um, I ended up going to work at an actual game company shortly after that called Gaspar Games. And then shortly after that, I started working at Rad Game Tools, which I stayed at for quite some time. Uh, and where I did like that character animation system and stuff. So it was, it was pretty quick into not doing that, but, um, it was still a pretty educational experience for me. And also what I will say is at the time, so I worked with there, a guy named Chris Hecker, who I have to give like basically complete credit to for teaching me basically about like reading technical papers.

1:29:12Casey Muratori:like before that time i just thought bath was kind of stupid and an annoying thing you had to do like in class right and i i definitely didn't know anything about like reading a siggraph proceedings really right um and i may have been like aware i mean i was aware of siggraph i knew what it was but i don't think if you'd handed me you know that binder i would have known what that was or what to do with it. Like, you know, I think like the biggest takeaway that I got from that, other than startups are hard and maybe don't do them, uh, unless you have a lot of people, a lot of funding and aren't really that much on the line, like maybe, uh, but, uh, the biggest takeaway that I got from that, that was positive was just a, a, a much deeper appreciation for math, a much deeper appreciation for research, how to read it.

1:30:02Casey Muratori:Um, that's where I learned to use like like Sightseer, which would be like kind of the precursor to like Google Scholar or whatever, crawling references and all that stuff. In a lot of ways, you could say, if I hadn't had that experience, I bet I wouldn't have given the two talks that we've talked about for most of the interview. Because what are those talks? They're me crawling every reference, right? They're just me going back and back and back and back and looking at everything that I can find. And that's something that if you, if no one ever conveys to you the importance of reading the scholarship and being aware of what's being done and also teaches you how to read a tech paper and how to parse through it.

1:30:41Casey Muratori:I don't know that you get that. You know, I don't know that you get that. I remember early in my career, I think there's this, I guess, common path of like these, you know, big companies. And then there's this thought of, oh, me and a couple of buddies, Let's go build something. Now with your experience, looking back, if someone out there is young and thinking about starting, would you say go that common path or would you say take the chance? You know, it's a really tough question. And I think that the advice, like the advice is that you have to think about what it is that you want to do every day.

1:31:25Casey Muratori:Like, so in my mind, the things I regret are the times when I've had to do things or chosen to do things that I wasn't really that happy doing every day. Right. Right. And so I think you just have to optimize for the experience you want to have because the startup might work out. It might not. It's always a risk. Right. You may go to the big company and, you know, it may be cool. There may be interesting things there or there might not be like who knows, like you don't really know. You're making a kind of blind decision. And so I think you kind of have to optimize for what do you want your day to day to be like?

1:32:03Casey Muratori:What do you want the experience to be? And you want to like, keep a running talent. Like you want to be aware of it. Like if you make a decision and six months in, you are not liking what you're doing every day, then you need to get out of that. Right? Like, that's my opinion. so i don't know i think most people probably if they sit down and actually like clear their mind and aren't aren't engaging in too motivated a reasoning but just for themselves go what do i envision working at the startup will be like what will i actually be doing every day like am i gonna like that is this gonna be thrilling like trying to make this thing work and like being kind of on the edge.

1:32:48Casey Muratori:And, you know, do I want the kind of war stories of like the things we had to do to pull off the demo or whatever, right? If all that sounds exciting to you and you want to have that experience, then you should do that thing. And I would say like, really, I really mean that. Like, I don't even think you should take into account, like even like, let's say, you know, the startup's going to fail. If you want to have that experience, then you need to do it, right? It's just like anything else. It's like going and backpacking across Europe or playing guitar at a nightclub. It's like, you may know that these things are not profitable.

1:33:24Casey Muratori:It's just, is that the experience you want to have? Are you going to look back on that six months or a year or five years or whatever, the amount of time you're thinking of committing to it? Are you going to look back and say, I'm glad I did that? Or are you going to be like, that was, you know, that's time that I would have rather spent some other way. Right. Right. And so I think most people can probably, if they're honest with themselves, at least make a pretty good guess. And that guess, if they're honest with themselves is going to be better than any advice I'm going to give them. Like my guess about what you should do is going to be worse than yours.

1:33:52Casey Muratori:So you should just make that determination because another way to look at it, it was like, you know, that the big company side of it's like, maybe you just want to have some security. Like maybe when you're starting out, like, I mean, I'll just give some examples. Like Like maybe you want to spend a lot of time dating. You want to find a partner and you want to have a relationship and you want to have a family. Maybe that's more important to you. Maybe the startup, yeah, it might be fun. Maybe it would be more money if it worked out or whatever. But like maybe the stability is actually going to be something that you would really benefit from.

1:34:26Casey Muratori:Because the sorts of things that you imagine being fulfilling in your life are not all around what you're going to be doing in computing. I think you can know, have some guess about those things when you, if you just let yourself have some space to think about it and don't engage in too much motivated reasoning about it. Right. And, and I think that would be the best way to make a decision if you're going to make one. That's my, that's my feeling about it. We talked a lot about video game engineering and I have no idea what goes into video games. If you were to just boil it down to the big pieces that you need for a video game, what are those software components?

1:35:06Casey Muratori:So the biggest thing that's different about a video game is that the sort of original mental model that you're taught in programming, which is like the standard IO, like I get some input in, I process it, I put some input out, is like not how it works, right? So the biggest mental shift is just like, oh, the way that a video game or a simulation of any kind works is I need to have some world state and I'm constantly updating that world state on a regular interval. Everything is always happening. There's no I wait for input and then I do something. Everything is always going because it is real time.

1:35:48Casey Muratori:Like the time is going forward. So the components tend to be built around this idea. and it depends on what level of sophistication you end up getting into. But in general, you need a way of storing that world state. So some kind of, we usually call these entities, like the things that make up a world, right? So some way of modeling what is in the world, where are things in the world, what is their state, what are they doing right now? So you need something that does that, something that is in charge of advancing that state. This is a mixture of several things. It could involve physical simulation.

1:36:26Casey Muratori:It could involve AI, not necessarily like large language model, like the modern notion of AI, but like pathfinding, making a decision between whether I should attack the player or not, like that sort of AI, right? So we have the world, some way of storing the world state, some way of advancing the world state, like an update step that may involve lots of things like that. then some way of presenting the world state so a renderer right and this is something that typically uh has uh i guess i would say it's it's traditionally been a very important part of game because the visuals are often something that is a selling point for games people produce trailers certainly in the triple a space we're trying to show you how cool the new lighting looks and the whatever.

1:37:19Casey Muratori:So that is a pretty big component of games. Oftentimes you go look at an indie pixel art game. It might be much smaller because that's a much smaller part of the problem. Now that's generally what, what, you know, the shape looks like. There's a lot of little pieces there. Typically nowadays we would have some way of asset streaming, right? The, the renderer needs to have things like textures loaded, models loaded, things like that. We need world data, physics, collision models, these sorts of things. They might be too big to fit in memory, or we don't want to spend a lot of load time to load them up front.

1:37:52Casey Muratori:We want to stream them in as they're necessary. So there's typically this thing that's sitting there, constantly grabbing things off of disk, caching things, pulling them in and out of a cache that's being used by the renderer, by the physics, and so on. So that's another common component that's new, didn't used to be there. There's going to be an audio and music system, obviously, that's in charge of when sounds are triggered in the world, ambient sound effects that are happening in the world, music that's playing, continuity. Again, all of that's interacting with the entity, with the world state to know which ones of those things are happening, the update step, which will be triggering things in that sound system.

1:38:28Casey Muratori:And of course, the asset streaming to load what sounds are being played or load the music. So we typically have that. And then, you know, I'm trying to think not, I'm trying not to leave out any major components. In a modern context, there's often networking. So we want to have a way for multiple of these game clients to communicate with a server. So typically what that means is that world, that state of the world is now, might be provisional. It might be sort of a predicted model of the world. That's not the real model of the world. The simulator is actually, the authoritative simulator is actually running on a server somewhere.

1:39:07Casey Muratori:And I am merely communicating with it to find out what the world state is. And then because I don't want to wait the late, I don't want the latency of like going all the way around. I am predicting the motion of things forward in time based on the last information I have. Right. So that's another kind of way that things tie in. If you want to start doing things like competitive multiplayer and all these sorts of things. Right. That makes a lot of sense. Cause like I used to play video games and then like these MMO are, you know, online games. And when When I start to lag, everyone continues forward.

1:39:43And then my internet catches up and then everyone jumps to where they actually supposed to be. Okay, that makes a lot of sense. I pulled some of your top tweets. I thought that might be interesting to kind of discuss. I'm sorry. So someone said, NASA does not allow recursion in their code. How crazy is that? And then you said, not even slightly crazy. And it went really viral. Can you explain why that's not even slightly crazy?

1:40:11Casey Muratori:When you're writing functions in a procedural programming language like we have, and that like NASA is probably using, you are able to use the program stack for storage. I mean, that's what it's there for. That's what local variables are. I call a function. I get some storage space on the stack. The compiler did that for me. It also saves the return address. So when I make a function call, that program stack is keeping track of where in my code I was so that when the thing that I called is finished, I get back there, not some other point. Neither of those two things are things you couldn't implement yourself.

1:40:53Casey Muratori:They're both things you could do. You could break the thing up into pieces. You could have ways of remembering what they were, like a state machine. You can have your own stack that you put your data on and access it. Right? So the only thing recursion really does is it allows you to leverage the fact that someone already wrote that code for you. And it may be more convenient to use because it's built into the language. Now, there are some things if you really want to get super technical about it, there are some things that happen at a CPU level when functions are called, but we can put those aside for now.

1:41:29Casey Muratori:If you want to talk about them after we totally could. So the reason that I don't think it's crazy to go like we're not going to use recursion to implement an algorithm is because if you're doing that you're kind of just yolo swagging that there's room on the stack for whatever it was that you were doing right and you can't even really check unless you're going to do some kind of weird like we could sort of do a thing where we go like okay let's try to determine how many more iterations how many more recursion depths we have before we hit the end of our stack we can do those calculations, but it's like, eh?

1:42:02Casey Muratori:And also if the compiler changed something about the layout, it wouldn't be true anymore and so on and so forth. So it's like, so if I'm NASA and I'm like, hey, I don't want my astronauts to crash into the moon. It seems much more logical to say like, don't use recursion. Just figure out whatever this thing was that you're going to do, turn it into a loop, keep a stack and make a state machine for it. We can reason about that much more clearly. We know exactly how it's going to take. It doesn't matter what compiler you got. It's going to work the same way every time. And it will know the bounds precisely, right?

1:42:33Casey Muratori:Very sensible to me, right? And again, you assume at NASA that they're not doing it for their health. They're doing it because they have, you know, hard constraints on the problem domain where someone's life is at risk and at, or at a minimum, many millions of dollars in equipment is at risk if you screw up, if, if you stack false, like if you, if you get a lot of money get something where you'd recurse 20 times and hit the end of the stack that is not just a uh oh i rebooted the computer or the or restarted the software right so so i don't know hopefully that makes sense andre carpathy had this famous tweet that kind of coined the phrase vibe coding yes and then you said if you thought software was bad today buckle up because it's about to get a whole lot worse.

1:43:24Yes. It's been about a year and a half since that tweet came out. The tweet came out February of 2025. Would you say that that was an accurate prediction?

1:43:35Casey Muratori:To be clear, I think it, the whole lot worse part is predicated on something that may not happen. And that is that the idea that we just kind of type some stuff into computer and ship it to prod, right? Basically like, hey, could you make me a thing and then publish it becomes a common way of doing things, right? For example, also done by people who maybe don't have a computer science background. I think it's fair to say, and that I wouldn't be being sort of overly dismissive of AI at this point, to say that a person who is well-trained in computer science using an AI to make code right now can make substantially better code than someone who doesn't know anything about computer science, who is just given, you know, fable and type some stuff in.

1:44:27Casey Muratori:Right. The difference is rather dramatic, I would say from everything that I've seen. So part, part of my, uh, concern that I was trying to express at that tweet was like, if the idea is like, we're just going to type stuff in and we're not going to really be checking the code, you know, someone who knows computer science is not really gonna be looking at it um worst case scenario it's literally just like some random person in marketing somewhere who has no idea what programming is just type some stuff in and hit crosses their fingers right i think we're in for a world of hurt right now it's a race so it's hard to say because it's basically a race of how good can you make the ai versus how much adoption does it get right it's a curve right it's like if you can make the ai good enough that the people who are adopting it at a particular rate are always using an AI that's good enough for what they're adopting it for, we wouldn't expect software to get significantly worse.

1:45:24Casey Muratori:If those curves go the other way, we're in a lot of trouble, right? So I feel like right now we're almost kind of teetering on this knife's edge. It's really, to me, it feels like a foot race of improving AI so it can be more autonomous and make better decisions without you needing to make them for it versus the capability level of people who are using it and the degree to which they're paying attention to its output it's like these two curves that are just like ah you know like what's what's gonna happen i don't have a prediction i don't know where we'll be in a year uh obviously for all of our sake i'm hoping that the ai curve wins uh because i agree like i understand certainly the perspective of people who maybe just don't like AI and don't want there to be AI.

1:46:15Casey Muratori:I can understand the wanting it to fail. I understand that, right? And I'm no fan of AI myself. So it's not like I'm going to criticize someone for taking that position. But at the end of the day, if you're talking about something that tons of people are using, you're going to kind of want it to be good. Like, I think at this point, given the level of adoption of AI, I really don't think it's would be great if it stopped getting any better right now. Like if this was as good as it was going to get, I think that might be bad. Certainly six months ago, I think that was true. And I think it's probably still true today.

1:46:57Casey Muratori:So I think ideally, if you want software to not be terrible, you have to kind of still be hoping that six months from now, the AIs are, again, significantly better than they were, right? Like that is the only way out of the current situation as I see it, right? I don't know if that's fair, but that's my sort of feeling on that. One of your other top tweets, it was, you know, Shopify put out this internal memo and you just, you know, you replied, you know, slopify. So I guess it's because in this tweet, it's leadership pushing the adoption curve, maybe harder than the capabilities of the AI in this case.

1:47:39Casey Muratori:Yeah. Although I also just like the pot. One of the things that I think is most unfortunate about the AI adoption as I've seen it is just the, because people think that it's going to be this major, I guess if I had to categorize the way it appears that companies are reasoning about it, they're assuming that if they don't get in early, it will be a big disaster for them. Right? Like, like there's a tremendous, like they don't just think, oh, well, we can just wait until the AI does what we need it to do and then start using it. They're like, no, we have to do it now. Like even before we know whether it can really do the thing that we want it to do or whether we know what the outcomes would be good, everyone has to do it right now.

1:48:21Casey Muratori:Let's do this. Right. And I understand why they want, why they're going about that way because they think that that is critical, right? They obviously believe that's very important. And to me, that's just kind of terrifying because as with any technology, the sane way to do it is to measure its capabilities, see how well it is able to solve problems that you have, see if it solves them faster than the way that you were doing it, and put it into a workflow at such a time as you've determined that it is a net positive. that's just the same like that's what you do with any technology right and you'd probably have like your team of people whose job it is to assess this thing and they're out there yolo swagging it right they've got 3 000 agents working on this cluster talking to each other and doing you know god knows what right and uh so there's gonna be that and someone's gonna be doing that but that should not be every org right like you wouldn't just be like everyone needs to use a ton of tokens right um Um, so yeah, like I, I do have concerns about that.

1:49:24Casey Muratori:I don't think that, that the way AI adoption was done was, was the best way for quality in software, but I would temper that statement with just the obvious fact that like, we were not exactly a five nines, uh, industry to start out with like software quality was really pretty low rolling into the AI era. So I always try to just also caveat most of the things that I have to say that might be critical of a particular thing happening with AI with just the fact that like, look, it wasn't particularly great beforehand either. A lot of this software was pretty low quality. And so you can't, some AI things may make things worse, but it's not like software was amazing and the AI showed up and ruined everything.

1:50:13Casey Muratori:That is a completely ridiculous narrative that is not true at all. Do you have any top technical book recommendations for any engineers that might be listening? No, I would probably use this opportunity to try to pitch reading technical papers. I think something that really the industry could use more of is people being more aware of what's happening, both like the historical papers, but also just current papers. It's daunting at first, to be sure. If you don't tend to read technical papers in your field, you will probably find it confusing. You won't know where to find them. You won't know how to approach them.

1:50:59Casey Muratori:Um, it will seem to take too long to read them because you don't know how to like skim them properly and determine whether it's worth your time to investigate a particular section of a paper and all that stuff. But if you're willing to spend a few months of just like, uh, at night, I look at a paper, you know, or on my lunch break, I look at a paper, you know, if you're willing to spend a few months of just doing that, you will get your bearings and you will start to know where the good papers are in your field. You'll know how to find them. You'll know where they tend to be published. You'll be able to read them much more effectively.

1:51:32Casey Muratori:You'll be able to know how to spend your time on them. And I think in all but probably a few small fields that probably exist somewhere that maybe people don't tend to write much papers in or something like that, it's tremendously valuable. And I think it's so valuable that I read papers in disciplines I don't even do. And I find it extremely rewarding. I read security research papers all the time. I don't even work in a field where there are security research implications. Games don't really do much of that. They tend to be run very sandboxed. Sometimes there are, but they're not that kind of thing.

1:52:07Casey Muratori:They're not like a web server authentication protocol or something like this. And I just find it incredibly rewarding because there's just so much good stuff out there that you can learn. So I would say that would be it. Instead of a book rec, I would say find a paper try reading a paper how do i go and find that you know first paper or some place to get started that will be valuable for most people who are watching because they they might be like generalists or you know work working in web dev or in just a tech general tech org at a big tech company or something like that i would say like pull up the proceedings of usenix uh u-s-e-n-i-x look through it for a paper that sounds interesting to you and try reading that paper or uh oftentimes there's a awards i think usnix has them where it's like best paper of the conference try to do the best paper of the conference see what you think um because that's like a that's a collection of papers that's usually about like operating system stuff and you know systems design stuff so it's going to be something that most people can relate to it's not going to be really esoteric like if you were to open up the proceedings of siggraph for example it'd be like oh uh you know neural networks for cloth simulation or something you're like okay like this is not i can't relate to this because i don't do graphics or whatever right so usenix might be a good place to start um but in general yeah like if you had another option would be to go to scholar.google.com which is their search that just specializes in like papers and type in a topic description that you find interesting.

1:53:51Casey Muratori:So like if you wanted to learn, maybe you were very interested in consensus algorithm, Paxos or something. And you're like, I don't know what that is. Or I came up at work and I haven't really ever looked at it. You can just type that in, Paxos, and there'll just be a list of papers. And they'll say a thing like cited by. You can see how many citations they have. That's usually how influential that paper was. I mean, to a certain extent. um so you know those are some ways you could get started and find something that might interest you uh and you know it won't be for everyone you may bounce off it but it'd be that'd be my recommendation is something to try you you might you might find it and then yeah last question for you is if you could go back to the beginning of your career when you just entered the industry and give yourself some advice what would you say so i think the advice i would have given to myself was to get into low-level programming earlier.

1:54:45Casey Muratori:I didn't really learn how to properly analyze and or even really write assembly language code until probably like, gosh, 2010 or 15 or like, I mean, it's recent because I'm pretty old and you know it it's like last 10 years or so or something right and uh and i feel like i always i always wanted to know how to do it and just never seemed to and like the the advice i would have given to myself i was like just just go like down the hall like what i was interested i was like go down the hall and like be like grab something like show me how the heck you write this that like, just, just show it to me.

1:55:36Casey Muratori:Like, right. I think one of the problems is, uh, a lot of people, especially when they're young, they are afraid of appearing like they don't know things. And I think that can be a real impediment to learning. I'm sure it was for me. And I probably like, just didn't want to like literally say, like, I don't know how, I don't understand any of this stuff. Like, can you explain it to me? And, uh, and I think that's one of the most useful things you can do. Like, I don't understand this. Please explain it to me is very useful. And most people will be very happy to do that if they're not a dick. Like most people will be like, oh sure.

1:56:10Like here, you know, um, now they might not be good at explaining it. There are

1:56:14Casey Muratori:plenty of engineers who are like really good at something and suck at like telling you how they do what they do. So you won't always get a great explanation, but sometimes you will. Sometimes you'll find the type of person who can explain very clearly how it is they do what they do. So if you just keep asking, you'll get the good explanation. Nowadays, I wouldn't really need to give myself exactly that advice because the internet has so much great information on it. I could have taught myself. That did not exist at the time. Awesome. Well, thank you so much for your time, Casey. I really appreciate it.

1:56:49Casey Muratori:Thank you so much for having me. Like I said, I love the show. It was an honor to be invited on. So thank you very much. Hey, thank you for watching this podcast. If you liked it and you want to see the show grow, please support with a comment or a like. Also, if you have any recommendations for people you want me to bring on, please drop a comment. Guests like Barbara Liskov, Mike Stonebreaker, Mark Brooker, these were all people that I brought on because someone left a comment. On another note, aside from the podcast, I'm working on building the ergonomic keyboard that I wish existed. Here's a glance at the prototype.

1:57:22It's a split keyboard. So there's two sides. This is in the case. But yeah, we launched on Kickstarter and we hit our goal within eight hours of launching. I really appreciate it if you were one of the people who grabbed one of the early units. We're now working on the long journey of building the tooling now. And so if you still want to pick one up, I've left the late pledges open on Kickstarter. So you can grab one there. I'll put a link in the description. Thank you again for watching the podcast. And I'll see you in the next episode.