When Casey Muratori stopped using C++
NNeetCodeIO@NeetCodeIO · 352K subscribers
- Views
- 31.6K
- 31,593
- Outlier
- ×3.4
- Median 9.2K
- Length
- 8:12
- Published
- May 17
- Sunday
- Comments
- 99
- 632 likes
Script
How it's written
- Words
- 1,680
- Words a minute
- 204
- Reading time
- 8 min
- Segments
- 6
The hook
0:00–0:26I think as much as you probably like talking about AI, I want to actually use this as like a way to to zoom out a bit uh maybe throughout your career or just your programming journey in general and ask you uh through the course of your career, have there been other things that I guess have turned you off or other things that because everybody is focusing on AI as if this is like a moment that is different from everything that happened in the past. But I think uh because you mentioned uh some people
Structure
I think as much as you probably like talking about AI, I want to actually use this as like a way to to zoom out a bit uh maybe throughout your career or just your programming journey in general and ask you uh through the course of your career, have there been other things that I guess have turned you off or other things that because everybody is focusing on AI as if this is like a moment that is different from everything that happened in the past. But I think uh because you mentioned uh some people think AI is not making you as productive as you think and I think there's evidence for that as well where it's kind of just like a perception type thing and that's not only the case I think with AI when you go back and I know you've made some arguments and you have uh opinions you can probably articulate better on this but things like the wave of clean code or object-oriented programming or even things like microservices and I think uh it sometimes it comes down programming or at least engineering and building things isn't so much like a science. There's a lot of like culture that goes into it and you can't really take the culture and disconnect it from like the way people are building and for example like cloud companies have said okay you have to do it this way and then you'll everything will be so much more productive and you and over the last several years I think people have realized that actually no you don't have to do that it's not it's not it's costing you a lot of money and it's not always worth it in a lot of cases and so I I kind of want to ask you you know throughout your career have you had other feelings like this before where you were just kind of turned off by
Watch from 0:00certain things. Um yeah, I guess I would say I definitely have been. I don't know how analogous they are to AI. Um I do think that probably the biggest sort of realization I ever had in programming was when I because I used to use C++ very heavily. um really early on. Like so after I kind of got out of high school, uh I learned some C++ and I started programming that way and I just assumed that like well if all these people who are like much more senior programmers than me at this point are saying that this is how you should do things, it must be how you should do things. Uh and then when I went to work at RAD Game tools, like none of the people there use C++ and I was like, wow, they're really good programmers and they're not using it. like why do I have to do all this stuff? And I sort of just did an analysis myself of like okay does do any of these things that I'm doing actually save me time imping stuff and I realized like no they're all just kind of a waste of my time. I could do it so much quicker and so much simpler if I just don't use any of these things right. Um that was definitely an eye openener for me I would say because previously I hadn't really had the realization that actually programmers in general as a culture often adopt very bad ideas.
Watch from 1:30That's just not it's not uncommon and it's not necessarily even their fault because it like you said um it's not a science. You know, we say the word computer science and sometimes we lump things into it. Uh, you know, if you want to talk about the pure mathematical aspects of something like uh complexity theory or something like that, then maybe you can call that similar to a science, although it's more of a math. But how you know, however you want to picture that, it is it is very um rigorous. Let's say like if we want to talk about analyzing an algorithm and proving that it has a particular you know time or space complexity uh that's that's real math like it's not like there's no handwaving there. It's not artistic in some way. It's just like yeah we we solved it like here is what it is. Um, but then there's other stuff like, should I put this thing in an object or like, you know, what is an object or things like that that people try to dress up as if they have that kind of a thing to them, but they don't. Like, we really don't have that kind of a um, you know, as much as people want to pretend that it does, it doesn't. And so we're definitely prone to going in directions that are just this is sort of what we thought was good and we didn't really have a a very empirical way to measure that because we don't even we still don't really even know how to measure developer productivity. Uh we you know in a rigorous way. People have tried it's not very compelling. Um and so I I do think that that's just a thing that we're we're likely to do.
Watch from 2:52Yeah. Which is one of the reasons to tie it back to AI. I've often said people who are predicting that AI won't be used because it's not good enough. That's like of all the reasons that AI might not succeed. If you thought if you wanted to make an argument that AI won't be around forever for some reason, that is the worst one. I'm like I'm like there is no chance that it won't be adopted because it's not good enough. That's not on the table because we've adopted so many things uh that weren't good enough in the past. That's won't be why. Right. So, so if you want to make the argument, I'm willing to listen to you, but it's got to be a different argument than that one. Yeah, I agree with you. But that's very like unfortunate that that's the case. But that's just how it is. And so, you know, if anything, AI at least is can be demonstrated to have done some things that were interesting, right? Like um taking natural language and turning it into uh like for example, an AI now knows which part of the code you're referring to in natural language. That's a big like that's a pretty impressive achievement uh in the history of computing if you ask me. Uh and we've adopted you know programming practices that have way less to show for them than that right. Uh so if you you know so anyway that's a separate issue but but yeah so just throwing that out there but yeah that's funny but you're saying that lines of code is not the best way to measure productivity which a lot of people are actually making that claim nowadays. Like it is if you use it the other way around. So if you uh produce the fewest lines of code but still ship as many features as someone else, that's a good metric, right?
Watch from 4:23Unfortunately, like I find that even in some of the biggest most impressive tech companies, they actually still use those. Like I think at Amazon, I I don't know today, but in the past, they definitely use lines of code. And um yeah, I think it's just kind of kind of crazy. Um it's a very bad idea because if you think about lines of code um it's not a onetoone mapping but if you just want to know how poorly a system like how many bugs a system will have how poorly it will perform etc etc all you really need to look at is the lock. If it's high, it will be slow. It will be buggy because you just like everything scales with that. Like the amount of machine code that will be produced scales with the lock, right? So that's just kind of how it is, right? Like if you start scaling to very high lock count, that will be harder to maintain. It will be buggy buggier. It will have more um performance issues, right? And that's just sort of a natural correspondence. Now you can try to construct, you know, if you wanted to say, "Oh, no, Casey, you're totally wrong about that." You could maybe construct code bases that were very carefully designed to have like 95% of their lines of code are never executed or something like that. Sure. But I'm talking about in the mine run of cases, that's just how it is. If someone can produce uh a you know a thing for whatever your use case is that's a tenth the lines of code of whatever you were doing, it's almost guaranteed to be faster, more secure, less buggy because
Watch from 5:54it's just it's so much easier to manage and the CPU can manage it more easily too because typically the more lines of code you feed in, the more lines the more instructions get, you know, churned out and fed to your CPU that at some point when you start when the lock increases to a certain amount, you've gotten to point where there aren't just like one or two hotspots of the code. You've created this sort of monster that has so much stuff that you're being asked to do that's never really going to run that efficiently. Uh and you've created so many possibilities for bugs because now I mean look at that that surface and not to mention security. Look at the size of the attack surface, right? And all that stuff. So anyway, kind of a kind of a mini rant, but like smaller less lines of code usually is better in my opinion, right? Yeah. I think most serious people would would probably agree with that as
Watch from 7:25Full transcript
- 0:00
I think as much as you probably like talking about AI, I want to actually use this as like a way to to zoom out a bit uh maybe throughout your career or just your programming journey in general and ask you uh through the course of your career, have there been other things that I guess have turned you off or other things that because everybody is focusing on AI as if this is like a
- 0:21
moment that is different from everything that happened in the past. But I think uh because you mentioned uh some people think AI is not making you as productive as you think and I think there's evidence for that as well where it's kind of just like a perception type thing and that's not only the case I think with AI when you go back and I know you've made some arguments and you have uh opinions you can probably
- 0:42
articulate better on this but things like the wave of clean code or object-oriented programming or even things like microservices and I think uh it sometimes it comes down programming or at least engineering and building things isn't so much like a science. There's a lot of like culture that goes into it and you can't really take the
- 1:02
culture and disconnect it from like the way people are building and for example like cloud companies have said okay you have to do it this way and then you'll everything will be so much more productive and you and over the last several years I think people have realized that actually no you don't have to do that it's not it's not it's costing you a lot of money and it's not always worth it in a lot of cases and so
- 1:23
I I kind of want to ask you you know throughout your career have you had other feelings like this before where you were just kind of turned off by certain things. Um yeah, I guess I would say I definitely have been. I don't know how analogous they are to AI. Um I do think that probably the biggest sort of
- 1:45
realization I ever had in programming was when I because I used to use C++ very heavily. um really early on. Like so after I kind of got out of high school, uh I learned some C++ and I started programming that way and I just assumed that like well if all these people who are like much more senior
- 2:07
programmers than me at this point are saying that this is how you should do things, it must be how you should do things. Uh and then when I went to work at RAD Game tools, like none of the people there use C++ and I was like, wow, they're really good programmers and they're not using it. like why do I have to do all this stuff? And I sort of just did an analysis myself of like okay does do any of these things that I'm doing
- 2:27
actually save me time imping stuff and I realized like no they're all just kind of a waste of my time. I could do it so much quicker and so much simpler if I just don't use any of these things right. Um that was definitely an eye openener for me I would say because previously I hadn't really had the realization that actually programmers in general as a
- 2:48
culture often adopt very bad ideas. That's just not it's not uncommon and it's not necessarily even their fault because it like you said um it's not a science. You know, we say the word computer science and sometimes we lump things into it. Uh, you know, if you want to talk about the pure mathematical aspects of something like uh complexity
- 3:09
theory or something like that, then maybe you can call that similar to a science, although it's more of a math. But how you know, however you want to picture that, it is it is very um rigorous. Let's say like if we want to talk about analyzing an algorithm and proving that it has a particular you know time or space complexity uh that's
- 3:29
that's real math like it's not like there's no handwaving there. It's not artistic in some way. It's just like yeah we we solved it like here is what it is. Um, but then there's other stuff like, should I put this thing in an object or like, you know, what is an object or things like that that people try to dress up as if they have that kind of a
- 3:50
thing to them, but they don't. Like, we really don't have that kind of a um, you know, as much as people want to pretend that it does, it doesn't. And so we're definitely prone to going in directions that are just this is sort of what we thought was good and we didn't really have a a very empirical way to measure that because we don't even we still don't really even know how to measure
- 4:11
developer productivity. Uh we you know in a rigorous way. People have tried it's not very compelling. Um and so I I do think that that's just a thing that we're we're likely to do. Yeah. Which is one of the reasons to tie it back to AI. I've often said people who are predicting that AI won't be used because it's not good enough.
- 4:33
That's like of all the reasons that AI might not succeed. If you thought if you wanted to make an argument that AI won't be around forever for some reason, that is the worst one. I'm like I'm like there is no chance that it won't be adopted because it's not good enough. That's not on the table because we've adopted so many things uh that weren't good enough in the past. That's won't be why. Right. So, so if you want to make
- 4:54
the argument, I'm willing to listen to you, but it's got to be a different argument than that one. Yeah, I agree with you. But that's very like unfortunate that that's the case. But that's just how it is. And so, you know, if anything, AI at least is can be demonstrated to have done some things that were interesting, right? Like um taking natural language and turning it into uh like for example, an AI now knows which part of the code you're
- 5:15
referring to in natural language. That's a big like that's a pretty impressive achievement uh in the history of computing if you ask me. Uh and we've adopted you know programming practices that have way less to show for them than that right. Uh so if you you know so anyway that's a separate issue but but yeah so just throwing that out there but
- 5:36
yeah that's funny but you're saying that lines of code is not the best way to measure productivity which a lot of people are actually making that claim nowadays. Like it is if you use it the other way around. So if you uh produce the fewest lines of code but still ship as many features as someone else, that's a good metric, right? Unfortunately, like I find that even in
- 5:57
some of the biggest most impressive tech companies, they actually still use those. Like I think at Amazon, I I don't know today, but in the past, they definitely use lines of code. And um yeah, I think it's just kind of kind of crazy. Um it's a very bad idea because if you think about lines of code um it's
- 6:17
not a onetoone mapping but if you just want to know how poorly a system like how many bugs a system will have how poorly it will perform etc etc all you really need to look at is the lock. If it's high, it will be slow. It will be buggy because you just like everything scales with that. Like the amount of machine code that will be produced
- 6:38
scales with the lock, right? So that's just kind of how it is, right? Like if you start scaling to very high lock count, that will be harder to maintain. It will be buggy buggier. It will have more um performance issues, right? And that's just sort of a natural correspondence. Now you can try to construct, you know, if you wanted to
- 7:00
say, "Oh, no, Casey, you're totally wrong about that." You could maybe construct code bases that were very carefully designed to have like 95% of their lines of code are never executed or something like that. Sure. But I'm talking about in the mine run of cases, that's just how it is. If someone can produce uh a you know a thing for whatever your use case is that's a tenth the lines of code of whatever you were
- 7:21
doing, it's almost guaranteed to be faster, more secure, less buggy because it's just it's so much easier to manage and the CPU can manage it more easily too because typically the more lines of code you feed in, the more lines the more instructions get, you know, churned out and fed to your CPU that at some point when you start when the lock increases to a certain amount, you've
- 7:42
gotten to point where there aren't just like one or two hotspots of the code. You've created this sort of monster that has so much stuff that you're being asked to do that's never really going to run that efficiently. Uh and you've created so many possibilities for bugs because now I mean look at that that surface and not to mention security. Look at the size of the attack surface, right? And all that stuff. So anyway, kind of a kind of a mini rant, but like
- 8:03
smaller less lines of code usually is better in my opinion, right? Yeah. I think most serious people would would probably agree with that as
Description
The Full Episode:
Youtube - • Why Programmers adopt Bad Ideas - Casey Mu...
Spotify - https://open.spotify.com/episode/4OeS...
Apple - https://podcasts.apple.com/us/podcast...
🚀 https://neetcode.io/yt - A better way to prepare for Coding Interviews
#neetcode #python
