The Standup with ThePrimeagen - Bullsh*t Engineers Say Tier List (Lost Episode)

Episode Date: May 15, 2026

This Episode never made it to Spotify for whatever reason, Original Air Date: 2025-11-20. Enjoy! We break down the most infamous "thought-terminating clichés" in software engineering. From the classic "It depends" to the controversial "Premature optimization is the root of all evil," the team ranks these common dev phrases on a tier list based on how much they actually hinder or help real problem-solving.

I already started it. What? We also know that you're late and you're streaming from a bathroom. I'm not in a bathroom, guys. It's a living room. Yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, sorry. Hey, everybody, welcome to the stand of today. We are talking about thought terminating of phrases in software engineering.

As you can see, use the right tool for the job. It depends. Premature optimization is the root of all evil and plenty more. We are going to rank them, which one is the least. least to most thought terminating of them all. F tier, obviously being most thought terminating, S tier being the least thought terminating possible. The best phrase you can say now,

not all those phrases are terrible. This is from a long discussion that's been going on on Twitter where people were all piling in what they think are thought terminating phrases. And so with us today, of course, we have Began Bot who was late and unprepared. We have with a trash dev who is also super duper awesome type tiero, right? He wasn't late a minute. Like not one. you were late for like 15 minutes it doesn't matter wasn't trash late too i wasn't here but i'm pretty sure he was

and of course casey muratory the actual programmer in this group uh real giga chad and computer enhance dot com check it out all right so there we go we got everybody out of the way so now we are going to be going to be going to be talking about all these different ones and if you've experienced them now casey you don't work in a professional environment like trash does when i say professional i just mean large stock traded company yeah has a bunch of people who have you said these phrases. Now, my time at Netflix, I've heard every one of these phrases. No way. That can't be true. Wait, trash, you're not hearing these phrases? I actually added this last one. Memory is free due to one of the directors at Netflix saying this about TV and driving people nuts.

Because memory was in fact not free and it was very difficult. Okay, so let's just start with... I'm surprised you heard any of these. You have not heard any of these? What are you talking about? I've heard half. I've heard half. Okay. Well, let's start with the worst one. And now you're on half. Sorry, sorry, I'm misspoke. Now I'm saying half. Well, one of the other phrases, one of the other phrases should have been like, you know,

integers. Everything can be represented in an integer. Let the record show that I said half and then I said none. And then I said half again. So I flip-flop. Round down to zero. Here we see the elusive programmer, a simple creature that spends most of its time working alone, often in darkness.

But what's this? Someone being wrong in the internet. Our coder springs into action, reaching top speed. of 120 words per minute before flash. A light mode website, the natural enemy of these code lovers, stuns our friend. The chase is called off.

We'll have to get them next time. When not on their computers, they can spend hours drawing crude symbols on something they call whiteboards. Researchers have discovered thousands of dialects, often with more than a dozen used in a single office. However, no linguists has yet deciphered what their purpose is.

Vane creatures, their bodies have evolved over a millennia to be able to sit in unusual postures while looking at themselves online. This will often last for many hours. Using the excuse, they're waiting for code review if pressed to why they're so inactive. And finally, after a long day of accomplishing very little, are keyboard warriors ready for bed.

Quick read and it's lights out. Good night, little coder. So how do I sleep so well at night? Well, I have century to help me crush those bugs. And I'm not talking about little teeny tiny South Dakota bugs that die in the winter. I'm talking about big, mean, jungle bugs. And I'm not scared of any of them, by the way.

But I can squash those bugs with Sear by century. Classic round down to zero. All right, so I don't really know which one to start on. Well, I know what to start with, Prime. You have to start with the worst one. I know what you can start on. I know the worst one. The one that is...

We should start with the most poignant one, the most obvious one. Never do a full rewrite. Okay, so that's a false statement, right? You agree. No, I'm... I mean, that's not... Like, the problem is, I guess, again, with your tier list, we're trying to say how harmful it is. It's not, it's not, because none of these things, you never really want to stop thinking.

So you never want any of them to terminate your thinking process for sure. What are you talking about, Casey? These are goals here. But, so we're just ranking by like, how harmful will it be if you terminate your thinking with this thing, right? That's what we're going for. And this one is actually, this one's actually pretty close to the bottom, I would say, because most of the time you don't want to do a full rewrite. So the chance of that being the right decision is kind of lower than probably what a lot of these other ones would be my guess. Am I wrong about that?

I am fully on your team. Never do a full rewrite is like by far one of the best phrases ever to say, excluding a few key circumstances. What are you guys talking about? Well, first of all, I know what's happening. You guys are C++-plus devs. So you guys aren't changing languages every week, okay? A new language comes out. We have to do a full rewrite.

I can't have half-rust, half-go. Like, you guys do... Full rewrites is how we sneak elixir in the stack. It's how we switch... Good point. Okay. That's why you don't have a job, B. Uh-oh.

I have a job. We have a point there. We have to rewrite everything in Rust, right up until Rust isn't the language we're rewriting things in anymore, and then we have to rewrite it in other things. Uh-oh. Why is Prime saying, oh, no.

I heard Aftram Prime, you know. Oh, yeah, I personally got F. If I cover up the screen by accident, if I cut it again, this is because Riverside won't give me our TMP feeds. But if I cover up Chrome screen, Chrome goes, oh, I can save memory and will then quit processing and all the videos drunk up and then it just gets terrible. Yep. That's a fantastic Chrome feature. It is a Chrome feature. I'm assuming there's a Chrome colon slash slash give me the real settings that you can turn that off.

You have to be some knobs. You're probably right. You know how they're like, like, if there's, if the thing with Chrome is if there's ever a setting that's actually useful, they will not put it in settings. It's in Chrome colon, go to slash, like sets. Hate it. Yeah, we're going to get Prime a second monitor. Everyone's sub. So Prime can afford a second monitor, okay?

All right. Hey, but seriously, never do a full rewrite. Began, do you actually think that this is a good idea? Okay, so real quick, I have told. people before I have snuck multiple languages in at companies. And the way to sneak stuff in companies is you pick a service, a small service in the microservice architecture and you do a rewrite of it. You say, I'm going to take the logging service. I'm going to do a rewrite of it. Hey, this thing like, I don't know, checks birthdays, you know, whatever. I'm going to go do a rewrite.

I don't have been Zig or in a quick little full rewrite. And that's how you sneak languages. How are you guys sneaking languages in at companies? Don't because I'm a professional. Wait, wait, wait, in trash. How are you going to make sure you don't get fired. By writing it terribly. Oh, okay. The old school technique. Okay, okay.

You use the old technique. That one still checks out. There's two schools of thought for not getting fired. You just did the first school of thought. You're the type script company and having one service and all go and you're the only go developer. Good job security. And then make sure don't ever help anyone learn how to use it. It's good stuff.

All right. So never do a full rewrite. So, but as far as like, alternating in some sense, there are times where you should do a full rewrite. So by saying this, are you not like effectively stopping the thought process and saying, hey, no, we can't. You can't suggest something else. Yeah, I mean, the problem that I see with saying never do a full rewrite. I mean, because the correct phrase would just be rarely do a full rewrite, right? The problem with never do a full rewrite is really the rewrite problem is about losing the sort of inherent, like, structure.

complexity of the thing that you already have. Because normally what happens is for a system that's of any sufficient, like doing anything sufficiently complicated, checking birthdays maybe is a good example of something that isn't sufficiently complicated. So maybe I'm with you that we could rewrite that. What do you mean? But for anything that has any sufficient amount of development time in it and that has been deployed and has some of that subtlety of like we've actually had to fix the things that are broken and improve the things that weren't working and whatever for a little while. There tends to be actually baked in knowledge there that no one programmer has completely in their head. And so when you go, if you do a complete rewrite of it, you will be starting

without that sort of baked in knowledge and you end up making the same mistakes again. Or you make mistakes that would have been prevented had you been working in that code base because they would have been obvious right away as you tried to do the thing you were about to do that was a mistake. And so that's really the problem with full rewrites is that. And so sometimes you're in situations where like, let's say that the code was written by people who really didn't know what they were doing and it's not working very well. And you've got some programmers who have done that thing before. So they actually have a bunch of experience and kind of know how to do this thing really well. In those situations, a full rewrite may be actually way better, right? So you do have to

have some kind of an understanding of exactly what situation you're working in. But if you were the programmers and you've been working, and this thing's been around for a year or two or whatever, rarely does completely rewriting it is rarely is that the right decision in my experience. What do you mean you programmers? Are you trying to say that? You. I'm trying to say that me and Began wouldn't be equipped for a rewrite service? Casey is an engineer. No, I'm not like you programmers.

Yeah, I meant you meaning you, whoever is making the decision, whoever's going to be doing the rewrite is the same people that did the service in the first place. So you were the ones who worked on this and you built it in the first place. Usually you just want to iterate on that and go, okay, we can, you know, we can rewrite a chunk of it. Like we can take a little piece and rebuild that. And then we'll take another little piece and rebuild that, right? That's a great way to go about moving it forward. wiping the whole thing

way too risky and so you have like it's rarely the right decision in my opinion I love the rarely it'd be great if we made every cliche more subtle and rare

but you gotta keep it just never I will say there is a case and I've been at companies where there's a piece of code by an engineer that's gone and they were on they were on something

when they were writing it they were going through a functional phase and experimenting with languages and they wrote something in a whole new pattern and then everyone tries and interacts with it and it's the most painful thing ever to add stuff to

and everyone's learning the ancient magic that Steve added two years ago. And then you keep trying to add to it and add to it. And finally someone says, can I just start over it now that we know what the product is? And they start over in a week later. Everyone's like, it's so easy to add features over here because we're not dealing with Steve's insanity. But the never rewrite can cause people to be stuck in Steve's code forever.

Yeah, I think the problem there's in addition to like the context problem and potentially the size of the app that you're rewriting is like you also, depending on how. popular your app is or is being used, you have to be able to deliver value while you're rewriting. If you go full rewrite, you can't build features because you're kind of just screwed unless you want to maintain two versions of it. So I've had those situations where we basically have like a forked version that was like feature flagged while we were like, while like some people were still working on the legacy version. We were working on the new one. I love that. Oh, wait,

you had a new feature? Oh, wait. I can't even like merge it because it's a completely different patterns. You have to like manually rewrite those again. So it's just like a huge like undertaking of like trying to make sure features are being shipped at the same time as a rewrite literally the worst thing ever. All right, so never do a full rewrite. What are we thinking? What tier? I'm saying that me personally I'm thinking it just falls near C.

I'd put it even lower. I'd put it even lower. Yeah. D? Yeah. I don't think it's harmful at all. I think that's a good, a pretty good thing. Like if that was your only thought terminating cliche that you did, I don't consider you particularly harmful. Yeah. Right. Put it all the way down on F tier.

Put it all way down because I actually agree with that. this is if this was the only one you did then i think you're pretty much yeah like that like i'm guessing we probably we won't hit another one that has less actual practical downsides than that one but we'll see we can move it if we turn if it turns out no then we'll move it but all right programmer time is worth more than CPU time oh god i have never heard this statement in my life yes you you've heard a variation of this statement where it's just like this is the this fundamentally this is the developer ergonomics argument or it's just like you will include

the kitchen sink because you wanted to write like three you wanted to write your code declarative in this one part you loaded your app a huge amount you know it's a Ramda right I think it's in TVI RANDA right I want it to be functional and I want my erity functions

and he's just like okay well you've just included a whole ass library because somebody didn't want to like write a function that returns a function trash we bring you over to the Ruby community for one day you'll be hearing this phrase all the When everyone's like, why is it so slow? You go, whoa, chill, chill. Our time's more important than the computers.

Relax. Let's write some code. DHH who's been on the show with us will say that, like, if he was on right now, he'd be like, yeah, that's totally fine F tier. Right? There's many people who that's just their philosophy of how they build things, for sure. Yes, yes. Yeah, the problem is with this, I think, this idea of like, oh, it's whatever, programmer time is more valuable.

People make super slow programs. And then they're just like, dude, I made that really quickly. five seconds ago and who cares if you guys are all struggling using it. Get bigger computers. I don't like that attitude. We don't care about performance by default. It's the new problem because he's youth. And so, yeah, I mean, and part of this is this going to be a matter of, of like, what your goal is, right? Because this statement probably makes some sense in a business area where there's low competition, right, which is a lot of internet business areas. There's a lot of places where there just isn't very much competition and there are like near monopolies on things.

And you absolutely can just kind of shovel stuff out, and like that's just how it is, right? So I would say, like, this is one where it really depends on whether you're talking about our goal is to ship quality software, in which case this is very harmful, or our goal is just we're a business and we don't care. And like, we just need the like bullet points to be there so that the sales team can say that they're there. And so as long as the thing technically does it, doesn't matter if it takes six years and no one can use it, right? So this is a tough one to place because I think it comes down to what are your goals with what you're doing and what does your business look like, right? So I would say this one and premature optimization is the root of all evil, which I think you said we also have on there. These are both going to come down to that, right, in a lot of ways. But anyway, so I would say this one, this one's probably, I'd put this one mid to high, like.

like B or C tier, personally. But again, it's, it's a, when I, all of the things that are, are bad for performance, it's actually at least not as bad as some of the other ones because it's honest, right? Like the person is not saying that they did a good job or that it's like fine or whatever. They're just saying like, look, I know I'm burning up CPU time

and we're just going to pay for more of it or something, right? There's a good difference. And I think people are mentioned, like premature optimization, the root of all evil is like the sister cliche to this one. The difference is, is it has this amazing word there, premature, which implies we're going to get to the optimization eventually. Don't do it now.

Right, exactly. Don't discuss that one yet. There's too much hilarity in that one. You've got a pair. I'm saying the problem with this one, though, is that it extends forever. We're like, act, our time is more important than CPU time. You're like, well, are we ever going to make it better? You're like, nah, our time's more important than it's, if there's, I'm all for, you know,

the first pass not being that good, but. You got to have a time where we make the software good, right? I usually just give it to each and say, fix this. And then he rewrite the new language. The excuse I hear is like, it's only only if we're going to be 100 items. It's not going to be that bad. Right, right, right. And then it just gets bigger and bigger and bigger.

Right. All right. There's a lot of items in there now. But it is true. It is true that 100 items is like a really, like that's one of those great ones where you're like, I'm only iterating over 50 items. It does not really matter. And often the most simple thing being an array is often your best choice in these like smaller

item count structures. And so that's why I like put in little hard limits on stuff. You put like a little fail case, panic case where it goes up and you know, hit it in dev mode and you go, okay, there we go. We whoopsie daisied. We can move on. But okay, so I would put this definitely probably in the B tier just because. Yeah, that's interesting with that.

You see this frequently, but at least it's honest, right? It's just saying, hey, we don't, we intentionally don't care. And so it does terminate a lot of thoughts. Now, obviously, GitHub, you still can't type long comments on there. and it's just horribly horrible and slow. But that falls under what Casey said. It's a near monopoly. So it does not really map.

They have no desire or need to make GitHub better. They're just going to make more co-pilot. It's like when you make software, step one, start a monopoly. Duh, start from the monopoly, then make the software. You're going to like be competing with people. Seen to a waste of time. True. All right.

Here we go. Let's let's pick one. I think this one. Okay, so this one's interesting. Don't repeat yourself. I'm not really sure how this falls. under this category of self of thought terminating things because this kind of feels like thought filled things yeah dude i hate that phrase so bad well it was a there's eras of don't repeat itself

i will say and like i would say maybe 10 years ago it was everyone i was not allowed to repeat myself i was not allowed to everyone above me was like what are you doing stop stop stop you just wrote the same thing twice oh my god we have to refactor it has to have and then i think everyone got over that as time went on and we said well what what abstractions we make a thousand million stupid abstractions. So I feel like this was when I was a kid, this was hot. This was all anyone said. And I would never let the same thing happen. This is actually a really big thought terminating because I can't tell you how many arguments I've had where people are like, oh, we got to refactor this to make it into something where we don't repeat ourselves. And I'm like, well, but right now it's simple. And if I combine these two thoughts that are very similar,

it's going to just make kind of a hellish config that I'm going to have to pass in to kind of swap between these almost near identical behaviors. Yeah, you know what happens? Like you'll make, you'll make, you'll make some kind of function or whatever your teammate will be like hey that looks like it would be helpful to me or somebody one day let's uh let's make it uh reusable and then you make it reusable and then no one ever you reuses it and it just sits in a fucking utile folder for like 20 years i hate i hate this you know what's made worse is that after it gets moved to the util folder no one can find it and so there's like seven versions of that same damn fucking literally my life dude every time i hate it oh my gosh okay yeah don't repeat your

I feel like that's like an S-tier level, like stop thinking. Yes. I've been at companies where it's like we make a U-Till folder. You make a U-Till library for the company. And then you make some stupid implementation for the simplest little function you've ever done. And then someone makes a variation of that function. And they go, oh, we have to combine them. And then they spend all day talking about how do we combine these two functions that are in two different services using a utility library.

We go, make another function? That's three lines long. He goes, no, no, no. We will debate. How can we get these things? It's just it's a waste. So I guess I'm the odd man out on this one. I actually...

Case is disappointed in our conversation. Well, it's more... I mean, I guess I can kind of see... So I do think that maybe we can make like a happy medium here and just say, when you're talking about a team of people, I can see why don't repeat yourself is annoying, because it's like, well, had I wanted to merge these two code pass, I would have, right? And so if someone else is telling me...

me to merge them and I didn't think they should be merged and they're using TRY to be the reason to do that. Yeah, I'd be pissed about that, I guess. So I totally am with you on all of that. But I just wanted to add the caveat that like when I'm actually just programming and we're just talking about when I'm writing code, I'm not talking to someone else about it, I often will just try to make sure that things are done usually only once. Like that's how I'm normally looking at things. Like anytime I see myself do something twice. I put that into a function that I can call to do that thing. And like, so I don't want people to get the impression that somehow you're just supposed to be...

Like, one of the things that I hated most about when you guys were showing me AI code is it doesn't ever do that. It just spams everything everywhere. And I'm just like, this is horrible. And like, the number one thing I would have said to one of those bots was DRY, man. Like, why are you computing the distance the same way in 50 different places? Just make a freaking distance function and it won't do it, right? So I just want to make sure that it is an important thing. It just might not be a great thing for when you're arguing with people about code.

Okay, so first of all, Casey does the thing that you, Casey and T always do this. I got to represent the dumb people out there. He's always like, I don't understand. You guys repeat yourselves? Oh, I didn't know that was the thing that you're doing. I just don't do that. Don't write code. Like, I think the difference is if it's your code and you're in charge, it's all good.

There's a lot of us idiots out there writing code. We're told they refactor that. Combine that. I got a function over here. No, that's why I'm saying. We totally get that. I totally get that. Like, that if someone's telling you that and you didn't think so, like, you looked at the code and you're like, I don't think they should be merged.

And someone was like, no, you got to because DRY. I could totally, like, as I said at the start, I totally get why that sucks. Well, I think there is another, there is like another part of this too, like, because for the AI side. I think it's good that AI duplicates a bunch of functions and doesn't try and refactor stuff until you tell it to. I would rather it's spam functions until we've gotten to something I like. then I can start saying, okay, let's start creating the right abstractions. Because we know if we refactor, if you say, like, I don't know, I need a distance function right now. And it goes, we actually don't know all what we're doing yet.

You actually might be pigeonholing AI into a corner where you say, do this dumbest, long, annoying thing that we know is right. And then we will talk about combining after. I think that's a good way to talk to the AI. Who's my friend? So AI out there. I mean, only if the AI is like an absolutely remedial programmer that I have to babysit, which is the whole reason that. I don't like these things, right? It's because it's like, I have to spend more time telling it to do obvious stuff.

So, yeah, I mean, if it programs like a beginner and beginners repeat themselves a lot, which is why I wanted to say, like, D-R-Y is not really that bad of a guiding principle if you're using it for yourself. But they're, you know, so as an argument, it's maybe not as good. But as a, like, thing you should think about, it's not bad. That's the only caveat I'd add. So that's it. Where are we putting it? All right.

We can drop it at one level. A. Okay. Okay. I like that. It's high. A lot of people, a lot of people work in teams.

I'm not sure how much. I don't know what the solo to work in teams number is. Like, I don't know what that ratio is, but I feel like a lot of people working teams. Therefore, we'll use it in that kind of way. Okay, we'll just move on. Okay.

The right, this one is by personal gripe, which is use the right tool for the job. Now, me personally, I put this all the way up here at S tier. Let me give you a quick reason why. What does it even mean? Can you tell me what it even? I don't even know what that means.

I'll give you an example. So let's just say that you're about to build a brand new web application. Okay. And it does not matter. Like I noticed that I didn't give any requirements or anything. There is already people that saying the right tool for the job is going to be you're going to want to be using X database. You're going to want to be using this, you know, what is it, clerk for authentication? You're going to want to be using typescriptful.

Like they already know all the things in like a vertical right away without with zero thought actually put into it. There's no like, hey, what are you building? Oh, you're building an internal tool. What are you building it in? Oh, okay. It's, you know, like people just pick the default thing that they really like. Really what the phrase should be is I use the tool I like the most for any job. No, no, no, prime.

You're all, you're completely wrong. Okay. So what I use I use I use code. I use Rust because it's no memory safe. So unless you like memory safety, it's a big problem. So that's the right tool for the right job, unless you are making memory on safe code,

then you should use C. Those are the only two tools, right? Okay, so basically what you're saying is this phrase, it doesn't really mean use the right tool for the right job. It secretly means something more like premature tooling is the root of all good, is what they're saying. Like pick the tooling right out of the gate and you're good. Don't bother waiting until you know what you need.

It's just whatever is hot that week, that's what we're going with. It's because all those folks are just making crud apps. So it's like cookie cutter. Okay, trash, there's nothing wrong with crud apps. Okay. And the world needs them, all right? You know that millions of people rely on crud apps a year to feed their families. So don't talk down on it.

I'm not eating crud. All right. Yes, anyways, I hate this phrase. I see it most often. It is just a way in which people, they don't actually mean the right tool for the job. because there are plenty of great distractions out there. And sometimes Rust is a really great choice for a language. I am going to throw it out there.

There's a certain set of problems that I actually really like it for. And guess what? It won't be used because people will be like, oh, we're going to use the right tool for the job, which typically, at least in my experience, means web dev chooses TypeScript to solve all problems on Earth, including how AI is now becoming solved by a TypeScript right now. There's a big push to try to make AI happen in TypeScript as opposed to Python.

And so it's just like, okay, this is not to use the right tool for the job argument. this is just simply I love TypeScript I will make it work in all aspects yeah ST is the worst I'm all for it well so this one is useful if you have an agenda right now once again I have an agenda when I work I'm trying to sneak code different languages into the code base this is how you sneak a language into the code base this is literally how you do it you're doing something in TypeScript you're looking for any problem like I'm looking for any problem I can that I can say only Russ can fix this

only we have to get Russ it's right to the right job come on manager you got let me rewrite yeah let me rewrite So this is a actual tech. I've used this to get Go into a stack that was all Python. I'm dying in Python. And I'm like, we need the right tool for the right job. It's too slow. It's concurrency. Go's whole language was built around a concurrency model.

It's the right tool for the right job. And they go, fine. So it is useful for accomplishing your own goals of sneaking languages and stacks. Well, the Python to Go train is actually a pretty good. That's exactly how we did it. It actually is the right tool, usually for the job whenever you do high computation. Gotcha. All right.

No one has any opinions on that one? Yeah, I got nothing. I'm begging, you're saying you don't want. Oops, he's wrong. No,

I get that it's an S-tier bad thing to be using. I would just use it for its bad thing. That's what I'm saying. He's saying it's bad and he loves that. Yes, and I use it for its evil. Yeah.

It's evil and I am evil. No, no. All right. Well, sorry, I know from my candle wall. I'm in like bombs house.

It depends. I hate to be meta, but I mean, it depends. on the context here. Doesn't it depend? It always depends, Brian. It always depends, you know?

I mean, that's got to be F-tier, because that's the right thing for most, that's true of most things. Like, what do you want to eat for dinner? I don't know, it depends. What you got? You know? Daybird.

The answer is always Daybird if I'm in L.A. That's what I want for dinner. I want Daybird. I don't even know what Daybird is, but I will have it next time I'm in L.A. Dude, it's so good. Oh, my God. Like, hashtag ad, Daybird is the most amazing...

It's the most amazing chicken sandwich you've ever had or the most amazing fish sandwich you ever had. Your choice. Both of them are amazing. Casey, you could have hit him right there with the best chicken sandwich or fish sandwich. What do you want? It depends. It depends.

Like, you could have hit them. It depends on which one you want. Anyway. All right, so we're saying it because, I mean, I hear this phrase. Whoa. And this doesn't really feel like a thought-terminating phrase. People are so wrong, Prime. You have net, you guys, this is the problem.

Prime worked at Netflix where there was no juniors. So you've never had this junior senior hierarchy. I've had seniors I've worked with who don't want to talk to you anymore because I'm annoying. So they just use It Depends until I go away. Like, hey, should I do this? Well, it depends. Okay, well, how do I decide here? Well, are using this or that?

Well, this. Well, so which I use now? Well, it depends. Are you doing, and they just won't ever give me an answer until they just kick me off. It is literally like you can cut people off. It depends. figured out for yourself. Yeah, I mean, good.

Like, it's a J. Junior Programmer. Go figure it out. That seems like a good. They're supposed to tell me what to do. That's a learning experience. It actually sounds like a thought inducing phrase, not a thought inhibiting phrase.

I'm the one as to think, though. That's the problem. It's me. I want them to tell me. Just tell me what to do. You're like, I thought the point of a senior programmer was just to tell me exactly what to type in so that I don't have to think about it.

I always have, it depends as a mode to never get anything done. As like you can, you can discuss add infinitum a problem. Like, you get problem masturbation going on where you just can discuss forever about a problem without anything because everything is just like a continuous,

like no one makes a decision because there's always an it depends. Well, maybe that could be a reason to put it up one from where it is. Like maybe, maybe there is like a case where it depends becomes like a, a, uh, what's the difference? What's the opposite of a virtuous cycle,

a death spiral? Like a, like it keeps, A sex spiral? A bald eagle sex spiral. So maybe, yeah, maybe. All right, that's good. All right, all right.

Are you ready? Let's see. Make it work. Make it right. Make it fast. Yeah, that's, that one's ridiculous. The, the problem with that one is like most of those kind of sayings. It completely removes the act.

It, it pretends that software. development works in a way that it absolutely doesn't work, right? So making something like work correctly, there is no difference between that and making it fast in terms of the actual structural requirements of the thing. So this bakes in, this is very similar to premature optimization of the root of all evil. It misses the fact that optimization is something that has to be planned for throughout the entire process if you ever want to make something fast. So making something work, the idea that there is a step of making something work with no regard to how it will have to run at the end, the only time that's actually a step in the process is if you

literally have no idea what you're doing. Like, I don't have any idea how this problem gets solved, so I just have to kind of go over here and just like play around with it for a little while until I can actually make something that solves it. If you're in that situation, sure, then this three-step process is correct. But most of the time, it's like, okay, I know how to sort a list of names or whatever it is. We all know ways you could do that. So me just sitting down and typing in one of those that works is not actually useful. What I'm supposed to be doing is going, what do I actually need to be delivering?

What are the requirements for that structurally? then I'll make it work, but it has to be in that structure that can be optimized properly later, right? And so the make it work part, if what you meant by that was make it work in a structure that can be optimized properly, then sure. But if it's just make it work, like, do anything at all, that's just a waste of time. All you were doing was just screwing around at that point, and that's not actually useful. So this one's tough for that reason. And the way that I see it used is usually in the wrong way, meaning I usually see it used in the way that I don't approve of, even though, like I just said, there is a way I could imagine that it being, like there's ways you can modify it so that I do approve of it. Does that all make sense? Yeah. Trash, Trash probably knows really well right now being at Netflix. Hey, Trash, how often do you get to make it right versus make it fast? I'm pretty sure your job, right, is the culmination of make it work for many, many years. And now they're like, okay, make it fast.

Yeah, we pretty much, at least, I mean, my whole career is, uh, let's just make it work. And then let's just hopefully it goes. So I feel like especially like in the UI space, it's really hard to be like, there's not, there's never been a concrete recipe to do something. So it's always been stumbling through. And then when it actually kind of works, you're like, uh, all right, then let's kind of like pick up the pieces as we, uh, try to tackle some tech debt. Um, but like if I'm doing more like scripting, like bash and like notes.

stuff, then yeah, I can definitely just have, I can make it right immediately. But if it's like UI, UX stuff, like, that's like, you're just like effing around and finding out that whole time, like for sure. So I don't, I feel like in my space or like in the UI space, it's kind of hard to, to be like, I haven't met anyone that was like, yeah, I know exactly how to do that. If it's like, especially if it's like a brand new like user flow or something, it's, it's never, it's never straightforward like that, if that makes sense. I don't know if you can relate to that, Brian. The only time that is, aren't you trying to fix the whole like type script compilation

like the all the LSP's never ever work when I was I mean the last time I opened up TBI which is granted it's been two years I even tried VS code and it would work for like one completion stop for like 20 minutes and then start again and then start again and it's just like it never worked ever and I was just like okay it's gotten so big and so unwieldy and so that's the whole make it work without any consideration to the whole make it fast side of things right well I think it's the big you never need the return types you know you know don't return types that would be terrible but it turns out that's like a huge performance went, don't do that, don't do that, don't do that. And all those things add together into

this just giant mess where it's like impossible or untenable to actually fix. And I would actually add one thing to that if I could, which is that the problem with make it work, make it right, make it fast, also it puts things in an order that almost, it almost encourages your organization to shoot themselves in the foot. Because as soon as you have something that works, someone will start using it, which then precludes your ability to change the API to make it right and to make it fast. So, like, a lot of times, like, the last thing you want to do is have a version that works properly, but that is wrong and slow. Never let management get that. Because as soon as someone gets a hold of it, now they base

the whole thing on it. And I think all of us have probably been in that position where we're like, wait, no, don't keep using that. And they're like, sorry, man, it's like the entire infrastructure now and you're like, okay, that's really bad, right? So I think, again, like, this one's pretty bad. It's a lot worse than it sounds, I think, in practice, because it sounds perfectly reasonable. You're just like, well, yeah, of course I've got to get something working before I can, like, debug it and make it work well,

and then before I can make it fast, like, that all makes sense. But I think it hides the real danger of this one. So I think this one's pretty bad. I put it at least at a B. Okay, so Casey, I do disagree with you, and I think this is once again, this is always the thing of, like, Casey being smart and working with smart people and lays like when everyone's smart and awesome in software these are you shouldn't have to worry about these things.

I've had this problem specifically where you have a senior engineer who works from home, who comes into the office once a month, who only has to submit a PR every two months that he merges in thousands of lines of codes for rewrites. And he'll go off in a direction and be like, oh, we need this great. I got an idea for it. I'm going to build the crate. And you're like, oh my God, dude, we just need this fix right now. Just make it work.

Make it good. I'm building the greatest thing ever. It'll go so fast and we're going to waste two months while this person tries to solve, boil the ocean. And we're just like, dude, just make it work right now. Please, please, please. We can make it better later. This does happen. And this phrase has helped me in my own life.

I think the difference is here is that some people only work in one of these slices. Like trash is saying, for me for years, you're only making it work, making it work. And then you've got a performance engineer coming. And they're only doing to make it fast. And someone comes in and they're here to refactor make it good. But if this is, like, if you're going to do all the steps, you are going to have time for like, you know, I'm going to spike something. I think make it work is like spiking like you were saying.

That's a good use case. And then from here we can write the code good. I just know, I know senior engineers who disappear for a month and come back with, here's a new library I invented and a whole new parent. I'm like, this is terrible, dude. We just needed the birthdays. Well, yeah, but that's going to be true of any process, right? Like, no matter what you say your process is, someone can just suck at it.

Right? And then that, but that doesn't really invalidate the fact that when you're doing, when people are doing something properly, that that would be the right way to do it, right? Like, no matter what we pick, you're going to have something like you could tell someone, look, just give me a version of this that works at all. And they'll come back with something that's like so bad that it's completely unusable, but they're just like, no, sometimes it kind of works when you start to call it, right? You can always imagine like a failure case.

But I'm just saying, like, in this particular case, when you're saying this phrase, what you're usually talking about is deferring any of the actual work that needed to be done. until some later date and like that's usually not a great idea if you know replace it with just something like if you are desperate and need something working right now just be like make a prototype or whatever like that's what we're doing we're just making that we're making a stand-in thing because that's all we can afford and just admit that you're doing that don't claim that somehow you're going to turn that into a right fast version later because that's that's a lie so just be like no we're just all right we're making the crappy version we'll make the crappy version that should be the

say make a crappy version there i don't have a problem with that if that's that's a That's what they can do, do it, sure. But don't lie about it. We can do make it crappy, make it fast, make it good. Or I think a good one we could do is we could say, make it work parentheses, but please don't ship it. Or let management know that we finish the feature, comma, make it fast, make it good. We just can't let management ship it. If you wanted an accurate one, it be make it crappy, throw it away, make a working one that's the fast structure but slow.

Make that right and then optimize it so it is fast. That's like the actual thing that happens, right? Anyway, we've got it tier listed. So I think are we happy with a B? Where are we at? All right. It's in a B. Okay.

All right. Okay. Okay. All right. Gagney, you ain't going to need it. You aren't going to need it. It's literally the ultimate self-terminating cliche. Like, it is literally too.

I don't know that one. Oh, really? Which one did you read? Yeah, I've actually never had it. I've never used in any sort of professional setting. We're in different worlds. This is where you're saying, hey, guys, like, we keep doing this thing. I'm going to build a library over here that can,

can handle these birthday conversions and then they go yagney you're not going to need it you're wasting your time writing that just just get back to see that on the list oh it might be have you ever worked somewhere that doesn't revolve around birthdays uh i just every example so far has been birthday he works at birthday dot coms we've already said this he brings he brings balls he does he's the best boy he handles birthdays got all the bee jobs yeah at ticket master and spotify my job entirely was birthday experiences. I got poached from Ticketmaster to Spotify to handle birthdays. They were like to

kill it over there. No, I'm joking. That would be so cool. It was like, yeah, we need a birthday guy. HR, you got to get us a birthday guy. We're dying over here. Galactus isn't working. Put that to my resume. All right. That's pretty good. I don't know this one, so I got nothing.

Yeah, I got nothing. None of you have ever heard this chat. You guys have heard this phrase right. You guys look in the different world. You've never heard Yagney. What was the phrase? You said you aren't going to need it. You ain't going to need it is the classic thing. You ain't going to need it. He put you aren't going to need it. You aren't going to need it. Can I just put it? Yes, absolutely. I have. Just throw it on there anywhere. Yeah,

I don't know this one. Sorry, no one knows. No one knows. Also, by the way, I had to go pick up my daughter here in 10 minutes and thanks for taking the first 15 minutes. Just have her on the podcast. We're never getting through it. I know. Keep going faster. All right. Pre mature optimizations is the root of all evil. Casey, I already know you have a strong feeling on this one. I mean, that's S.

That's like, it's never correct. Like, you never say that. It's a meaningless statement because it is baked into it, the fact that somehow you already know when you should optimize, because premature could be any point in the process. So it's a non-statement. It tells you nothing. And yet people say it as if it's telling you something. Worst, worst one probably by far.

Agreed. You both, I think it's, oh, my God. This is the one I was like, well, that's the only really good one. I was like, that's F tier. literally that was my mind anything nobody what's when is premature it could be like right at the beginning of the project might be the right time to do something so it doesn't tell you anything it's like a non-statement how can you optimize something that isn't working yet how can you optimize something that we don't have data on how it's being used by the customers who knows because it doesn't say

the statement does it just says premature so all it's all it's saying is like that that if you magically knew when the right time was that's when to do it yeah no shit like like obviously that's the it tells you nothing it is a non-statement and yet people use it as if it means never optimized your code, which is a weird thing. So, yeah, the statement doesn't even get used with its own meaning.

So it's horrible. Like, it should just be retired. So your whole problem is we just don't know when the word premature occurs. If we can... No, I mean, for you, what's premature versus not? Premature often occurs when your service is falling over in production due to traffic and it's costing way too much. And management is super upset at you. Yeah.

Like, that's as far as second. is until the uppers go, why is this costing this many zero to fix it now? And it's just like, okay, premature has now officially left. We are now... Yep. So we have now... We have proof that premature is not happening anymore.

Yeah, there's like a series of people that can be mad at you. Anytime they're not mad at you, that's premature. So once building's mad at you, once the customers are mad at you, once management's mad at you, we've hit mature. And so now it's time to optimize. But do not optimize something unless someone's yelling at you. That makes no...

God. All right. You're really ruin Casey's morning. All right. You just need to be disciplined. I don't know that one. Dude, if someone said to me, they can't hit in the face. I thought you were jujitsu guy.

I thought you'd get on the ground. Get over here. Throw him. Put him in a rear naked choke. It's like, excuse me? I need to be... Why do you have to be naked to put them in a chokehold? It's a rip. Shut up. Because you can get closer to the skin. Okay?

The arm is naked. Skin is getting contact, just like a baby in their mother. That's how I like it. Yeah, that's not a programming statement. This one was on that list that went viral. And I was like, are people saying this? It's that I've never, I don't hear people. No one said this to me.

I think this is like a shot at sea. To me, to me that would be S because that would stop all my thoughts. Because I'd be so pissed. He would have instantly fight. So that's ass. Okay, great. Yeah, I'd be like, that's like fighting words.

Like, what do you mean? And he'd be disciplined. And then trash immediately gets naked and puts you in a turpull. Don't make me Hold on, let me get my shirt off The hoodie's coming off It's coming off I would encourage everyone in chat

To look up General Butt Naked right now A real historical figure For whom this was true Alright I'm on my Wikipedia Can I actually Google that? Yeah Oh it's real historical figure

Like there'll be a Wikipedia entry General But Naked Yes We got all right We got a way too scared Next one next one while he does Get it, trash. Use my phone.

Best practices. Now, I got one for you guys. I was in the process of making a thing. This was with a certain aspect of where trash currently works. And I named my private variables without an underscore. And we had like multiple days long thing, even though it was marked private in TypeScript. And if you used it in TVY, it would say,

hey, you can't use this because it's private. All that good stuff. They're like, well, you have to put underscores. because it's best practices. And I'm like, but why? It doesn't make any sense. Like, why do you need underscores because it's best practices?

It's not even a thing. And so then it became this whole argument where the reason why I had to go back through and un-underscore things was because of best practices. But there's no actual thought there for me. So for me, best practices go way high. Just because I'm fine with negative experience.

It's just it feels like something people say to propel on something that used to happen without any reasoning or measurement why. Like I had another one where someone told me that I had to do it. Like, it was like a literally a year-long project that ended with me going, actually, if we would just write the thing normally, it would be way better. And all of these best practices you stated actually were completely false and under misunderstandings.

And that's that. Yeah, I mean, I think the problem we have in computing is like it's not, none of the best practices are like from a science. Like, they're not things that people have proven. They're just something that somebody said and like got popular because there was a book or whatever. So, like, best practices usually just means, like, uh, witchcraft or voodoo. It's like a thing, like, we waved this type chicken around and we think that makes the code better. So I hate best practices as a phrase is it's not so much that I don't think it would be great if we had best practices that were actually best. But the problem is that's never how it's used.

It's used for like stupid stuff. Yeah. What we do is we avoid that whole argument. And if we feel strongly enough about it, we'll write our own custom lit rule and just enforce it with tooling and then call it a day. Like, don't even ask me. Like, if we care strongly about it, our tooling will do it for you. So, well, some people will tell me, like, I'm like, I'm doing some front and I'm trying some React. I've got Tan Stack, Han, Hano, 1,000 things.

And I'm they're like, well, here's the best practices. I always ask the same thing. What were the best practices last month? And they go, oh, it's totally different last month. And I go, the month before what was it? And he goes, they're different every month. And it goes, you get a new set of best practices every month and you get an upgrade. It's really fun.

That sounds like just a fun way to build a business. All right. Real programmers don't make that. mistake. Oh. That's a tough. That's a tough one because they definitely don't. Um, but like, it does, that's not helpful.

Like, it's like, okay, so they definitely don't make that mistake, but you obviously did. So this is not helpful. That is S tier for sure, right? Cause that's just like a showstopper. It's more, it just is more antagonistic. It doesn't actually deliver any real. any real value? No, yeah.

Maybe a list because it's so bizarre. Yeah. Casey, sometimes you gotta bully the juniors a little bit. The first time they drop a database, that's a good time to haze them. And that's when you hit them with this phrase and you get them down. You say that to me, I'm getting naked. I'm jumping right on you. I think the worst, the one that's worse than that that's related would be,

I don't make that mistake. Because then if, like, if I'm arguing for that, like, I'm like, okay, yeah, maybe I don't, but like what difference does that make to the other people in this discussion, right? No, it's it. That is very, very true. All right. Fast, cheap, good. Pick any two. Is this even a discussion you get, Casey? Is this something you're even familiar with where you're at? That is the one that I like probably have heard more than you guys, I'm guessing, because that comes from hardware, the hardware world. and it's totally true.

That's just, I'd put that in F immediately because that's just accurate. We found one real one. This is great. Yeah. I largely, I actually largely agree with this one. I've never, you can't really do something fast and good. Well, I mean, the only problem is that you can't really pick fast and good, can you? Like, can you actually say, hey, we're going to write this software fast and we're going to write it good?

Well, okay, to be fair, it's, again, more from hardware. It's like, look, you can have a fast good. thing but will be very expensive, right? It's your Nvidia 5090. We used the reticle size dye and we made this gigantic honkin thing that cost a billion dollars, right? So it's usually more that way. In software, because we're so bad

at it, like, yeah, I agree. It's less relevant in software perhaps because we still won't be able to make the fast good one, no matter how much money you give us, but you know, aspirational fantasy, I guess. I feel like with software, it's going to be under-delivered, over-promised,

expensive, and not that good. Okay, so maybe move it up to D. Let's move it up to D just because it's software. In hardware, it would be down at the bottom. Yeah, that's because there's actual, there's real numbers you can play with there. Well, this phrase is actually very, very incredibly useful when you're talking to management sometimes. Because the cheap is one of the most important things that I've come up where it's like, guys, we, cool, I know you want this. See the cheap one right there?

It's going to take a minute and it's going to cut. We're not have these four devs on it. Or we're going to have to beef up this part of the cloud or whatever. This has been a helpful phrase. used fighting with management to do code correctly or get more time. It's been helpful, not thought terminating. Yeah. Well, it is, it's thought terminating in the sense that you want management to stop being like, just do it. It's easy. Let's go. You're like, no, actually, it's really, really hard. And you're giving me a four-person job and you want it done quick. Like, this is

going to be bad. I mean, part of the problem is that in software, when we think of cheap, what we're thinking about usually is how many, how much developer hours it took or whatever. And unfortunately, in software, you know, we have mythical man month problems where it's like the more people you add to a team, like the slower the development goes and stuff like that. So it's hard for us to go like, unlike hardware where there's a physical cost. So we're normally talking about the physical cost of the thing. There isn't that like sort of direct relationship of spending more money and getting more. In software, we don't really have that, unfortunately, right? But but yeah. So that's why this phrase is maybe not as good in software, but still less harmful than a lot of the other ones. Well, unfortunately, I do have. to go. So hey, everybody, that was a fantastic stand-up. I'm sorry that we had to end it so abruptly thanks Began. But I'm kidding, Began is awesome. No, it's my fault. This was actually

really, really good. I actually pretty much agree with everything here, and I've heard most of these phrases, so it's fantastic to see them here. So thank you very much are all of them ranked? Yeah, we're all ranked. Okay, cool, so take a screenshot of that, put it up, put it on Twitter. Everyone argue with it in Twitter. Great work, everyone. We did it. We did it. We did it.

All right. Thank you very much, everybody. I hope everybody enjoys today. Bye-bye. Bye, chat.