Lex Fridman: recommendation

Transcript context

…You talked about this idea of putting asserts everywhere that effectively crash the program when you have some state in your program that should not be represented and you have made this choice actively. And so I’ve never done that before. And I know this is like an old technique and I obviously must be too young or too dumb to know that this was a thing people did. I grew up in Java and I think that’s probably why I didn’t run into this. So I saw that and I was like, I’m curious about how to use asserts more. And then I ran into a person named Joran. He’s the CEO and creator of TigerBeetle. It’s like the world’s fastest, greatest financial database. And it was spawned out of a company that needed to do a bunch of financial transactions. And it’s written in Zig and what they do is they do deterministic simulation testing and they just use NASA’s kind of guarantee for creating really great software. So don’t use U size, specify your exact size of int you expect everywhere. All these kind of things they do to be very specific. And one of them is that every function should contain two asserts. Whether it’s positive space like these things should happen or negative space, like this pointer should never be null. You’re programming into things that should never happen. Normally, you would just never specify that. You’d never think about that. So every single function everywhere has all these asserts and these asserts run both in production and in testing. They’re always on. And then they take deterministic simulation testing and run like 200 years of just random data, just complete slop going through the system and seeing how far it goes. And when an assert happens, they’re like, here’s the input that caused it, here’s every last little bit that happened, and now you can identify where this went wrong. And it was so cool. So between you, John Carmack and Joran, that’s where I got like, okay, I got to really… And NASA, I’ll throw NASA a bone as well. NASA can join in on that one. I was like, okay, I want to try this. And I did try it. I built this big reverse proxy for me trying to do some game development stuff. And I just went ham on the asserts. And then I built the whole simulation testing thing that could do everything deterministically. So even the result of requests would all come in specific orders. And I found a bunch of bugs that I just would never have found. And then I did it for a game I was making. I found some bugs where my cursor went off-screen, it would cause all these different problems because I just never tested them. And it’s super fun and it’s like a really great way to program. Yeah, I think it’s a skillset you grow over time. It’s not just that you have to specify the preconditions, everything that has to be true, it’s also adding things that are like, you might not even think about. You have to sort of anticipate really weird things. And if you add asserts, especially in complicated functions or in complicated classes that are able to catch really weird things, that’s going to save you so many headaches and it’s going to help you learn about your own code. This is one of the things, I think it was Jonathan Blow that either in conversation with you or was it in a presentation, he said that when he’s starting in a project, he usually doesn’t know how to implement it, how it’s going to work. And I think he was saying that he wants a programming language. This might have been a criticism of C++, I’m not sure, where he wants a programming language that makes it as painless as possible for him to not know what he’s doing, how he’s going to implement it, and to quickly get to a place where he figures it out. I think there’s a fundamental part of programming is building stuff while not really knowing what the next thing you’re doing is. You kind of have a loose design, maybe a strict design, but really you’re solving puzzles that are not… It is a dark room in a fundamental sense. And there you have to anticipate the kind of weirdnesses that might emerge while not really knowing everything. Just this full fog, fog of war. And there that’s a real skill to anticipate the kind of issues that might arise and put a asserts on top of them. And it’s also like spiritually, for me, been a really nice way of programming a building of living life as having very strict asserts that say, “You’re going to fix this problem if it ever arises. You can’t just look the other way.” This idea of treating warnings as errors. Make sure your code compiles without any warnings. That was a big leap for me. It’s like, but there’s so many of them and it’s not really that important. It’s like, no, no, no warnings. Make sure you treat every single problem, even fuzzy problems seriously, because that’s actually long-term is going to create code that’s much easier to work with, much more fun to work with, much more robust, resilient to all kinds of weirdnesses, all that kind of stuff. So it’s a different way of approaching coding, probably more NASA-like versus web programming style. But yeah, it has made programming for me personally, much more fun because one of the most painful things about programming is creating when you get past 10,000, 20,000 lines of code and you have to find a bug. And that bug can take hours, it could take days to find, and that’s torture. Yeah. When your system gets sufficiently large, some of these bugs are just, they are very difficult. Bless anyone’s soul that’s working on million line code bases, because it does. I can’t tell you how many times I’ve spent multiple days just trying to figure out the root cause of the bug. Not even the fix. Just like why does this happen? And that’s hard. So I love that. I just love the asserts because I’m not good at them, I can see it’s definitely a skill that I don’t put into practice constantly, which means it’s just not like a muscle memory type thing. And so it’s just one of those things I just love. It’s such a fascinating way to approach a problem, because I would’ve never thought, you know what I’m going to do? If I’m wrong, I’m going to crash this thing and I’m going to crash it right here because I should never be wrong. But instead you’re like, “Oh, actually that makes perfect sense. I should crash this thing. I’ve done something terribly wrong here. Why would this ever exist?” And then you’re like, “This is going to solve a whole class of problems.”…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.