The Standup with ThePrimeagen - Don't Clean Code! with Creator of HTMX

Episode Date: May 27, 2025

Twitch https://twitch.tv/ThePrimeagen Discord https://discord.gg/ThePrimeagen ☕ ssh terminal.shop 📘 Carson’s book: https://hypermedia.systems 🧠 Grug Brained Dev: https://grugbrain.dev Timestamps: 0:00 Intro & chaos before the call 1:45 Meet Carson Gross (HTMX creator & professor) 3:29 What is "Coding Dirty"? 5:12 Why Carson hates small methods 7:24 The myth of clean code and method size 10:06 What the data actually says about long functions 13:11 Why abstraction is not free 15:06 Long vs short functions: maintainability & changeability 18:00 Why small functions make debugging harder 21:34 Beautiful at any size: the case for fat functions 24:19 The myth of good naming solving complexity 26:55 TDD, unit tests, and when they help vs hurt 35:39 End-to-end testing: the good, the bad, the bloated 43:23 Meme culture, cringe, and developer humor

Okay, so I don't really know how to introduce today's stand-up. T.J, are we recording? Oh, we're recording. We've been recording. Oh, we're recording. Okay. My wife is calling me. Of course, she's going to, here. Put her in the call, dude. Discuss it. Discuss amongst yourself. Hot mic in. What are we talking? Guys, what do we talk? I have stuff to do.

What are we doing today? Well, so for me, I'm a little bit blocked on QA. They told me they'd be able to finish everything by, end of month last month but sure enough fours turn to fives and so that's where I'm at I'm mostly mostly blocked on them I've been updating documentation but that's it that's an update from my end Carson I'm dealing with student grading and trying to figure out how GitHub actions work and I don't know it's going to be it's a long way a lot of points there's a lot of points on the board right now. I thought everyone just got A's these days. What happened to that? Yeah, I know. I try not to be like that, but it is easy. It's like, it's like, it's easy. Look, if they're going to use AI to write

their papers, just use the I to grade them. I tell the kids like, I know, exactly, I tell the kids, like, look, I'm a good, I'm a pretty good programmer, and I can teach you how to program. All right, here we are. All right, here we are. All right, we're all set, prime. See you later. All right. You guys already had a stand-up? Hey, I have no blockers. I have no blockers. No blockers. Wow, I'm very blocked. That's why I haven't got anything done. Can you explain why you haven't turned in any code for three weeks? I've been committing a bunch. It's just all configuration for my new arch install. So, like, I'm unblocked committing so much configuration. You're still sharpening the axe, I see.

Sharpening the axe. You have no idea how sharp this axe is at this point. Today we have a special guest on. We have Carson Gross, professor at Montana State University, author of HTML of HTMLX, which is a web, is the, how do you describe that? It's taking every popular trend on the internet and doing the opposite of it. And at MSU, he teaches system programmings, databases, and operating systems. Did I get that correct? I teach compilers.

I don't teach OS. Okay. I don't want to teach a less. I don't playing on that one. Okay, so just classic embedded systems guy writing web frameworks is who we've invited on. And again, normally we have Teage. Teage needs no introduction. He streams, by the way.

And Casey Murat Dori, amazing game dev and computer enhance.com. Am I right, Casey? You are. You're right. Also, avid bird enthusiast. Avid bird enthusiast. Ornithology specialist. Exactly.

Many people are wondering why Trash Dev isn't here today. It's because Carson figured out the one password and Trash is locked out of his account. Yep. As soon as Trash successfully resets all his passwords, he'll be back on the program. Unfortunately, he has an alphabetical order and he has to go through every single website to be able to have his one password back in. Trash dollar sign one. All right. So with that, today we're going to be discussing a special topic, which is really the, what is it, the, the

bizarre world of clean code. It is coding dirty by Carson Gross. Carson, why don't you give us a quick introduction of what coding dirty is and then maybe your kind of stance on why people should consider coding this way? Well, you know, I have to say like, so thanks for me on. The Coding Dirty was an essay that had been kicking around my head for for a long time. And, you know, you guys have talked to Uncle Bob, who's the clean code guy. And that clean code essay or book, I guess, sort of came out of like the agile world.

Like this, and I had grown up, like when I was, when I first started programming professionally, Java was like, yeah, there you go. Java just, like, started being the big thing. And so I kind of grew up with, like, the patterns and, like, the agile manifesto and then test-driven development. A lot of that stuff was really baked into the world that I was in. And so I just finally, like, got to a point at it. I'd always, there was something about it that didn't sit right with me. And so I finally just was like, you know what, I'm going to write an essay and try and like sort of go the other way with it. So,

and there were, you know, I do, I do have to say there's a lot of stuff. And Uncle Bob, he's been a really good sport on Twitter. So I've got, I don't have anything bad to say about he was a cool guy on Twitter, like the last couple days. But, uh, the, there were a few things really that stood out to me when I, you know, you guys had had him on to talk about clean code and all. that stuff. And I was like, you know, I just got to write this essay that talks about the way that I write code. And one thing I do in the essay is I say, look, I'm not saying you need to write code this way because the way that I write code isn't necessarily the way you're going to write code or whatever. But that's okay. But I want to show that, like, I've had a pretty successful programming

career, and I do things pretty differently than the clean code suggests. And so, like, the three things that I really focus on in the essay is, number one, like, I think methods can be big. Like, I've got no problem with, uh, actually very large methods. Yeah, exactly. I like big methods. Um, and, uh, I also, I'm not a huge fan of unit tests. Um, I like that. I don't want to say I'm not a huge fan. I like, I don't use unit tests to drive my development is I guess the way I would say it. And then the last thing that I'd say is I really think, um, particularly in the Java world, um, and this appears to be the case to at least some extent in the rust and like the other and type script and so forth. Like I I think there's often

too many classes. Like we expose too much stuff to end users and we just try and like, you know, decompose everything and, you know, it tends to lead towards what I would consider over architected code. And I think there's some good ideas. Like, for example, you know, a class should be coherent is something that you'll hear, you know, very smart people say, and that's true. But also, if you worry too much about coherence, where every little thing has to be its own class, then you get into this sort of morass of code. So those are sort of the big three points that I wanted to talk about. And, you know, I'm happy to drill into each one, if you like.

T.J. got a book. I was waiting until later to pull this one out. I figured if I have one book, I have to have the other. Hypermedia systems, guys. That's a good one. one. It's a really nice. It's an excellent hard cover, beautiful cover, by the way. Yeah. Available on Amazon.

Look at this. It's wonderful inside. I've read a cover to cover. No lie. Thank you. I appreciate that, Tuge. Mm-hmm. Yeah. That's a borgon. I was waiting to pull that out, like, as a prop later, but you kind of outed that I pulled it there. Like, I got both. Let's pull it out again as a prop later because I'd like to know more about this book,

but now it's probably not the best time since the I was supposed to be talking about the 3D Codes. So let's let's bring that again, though. Keep that handy. We'll bring it back. circle back. We have to do a stand-up language. Sorry, we'll circle back. We won't take it offline. We're going to leave it in the stand-up, but we're going to keep it online. Yes. Keep it online. That's the name of the game for us, for sure.

Yeah, so I would say that this is one of, it is definitely a big departure from what is adamantly stated in the official quote-unquote clean code lectures and book to say that you're going to have larger functions.

Right. Like larger function seems to be something that is is extremely, portrayed extremely negatively. And it's not really immediately clear why. As with many things like no empirical evidence is given for this and also no examples really are given for it oftentimes. Meaning there aren't like normally if you're going to do architecture stuff, which I have given lectures on in the past briefly. But, you know, it's not something that I spend most of my time talking about. If you're going to do architecture stuff, you should at least have like gamed it out. Like, okay, here's all the ways we could have written this. And let's look at each of them and see, like, what is the benefit, what's the drawback? And we're going to try a couple different things. So let's look at a function that has this kind of properties. Let's look at a functions that have this kind of properties. And what does it look like when they're bigger or small?

None of that happens, right? It's just, hey, they should all be small. Next thing, right? And it doesn't, it's all vocab, right? It's all just descriptive, but doesn't actually show code. and then when you actually do look at some code like the example code or something in clean code, it's really bad, right?

It's like there's so many things I would criticize about this, and I picked one small segment for the Clean Code horrible performance video, right? And just said, here's all the reasons I think this is terrible, right? But that's just one snippet. You could do that for everything. And so I would say that, like, you actually cited in your essay an actual study, right, from Code Complete where they looked at it. And I guess what you were saying is they found

the opposite is that larger functions actually don't have empirical evidence against them so much. If anything, it's slightly for them. Is that correct? Yeah, so I do cite a couple of, there's a book, an older book called Clean Code, which talks about method length, and the studies they went through suggested that actually longer methods are higher quality and that there are fewer lines of bugs per line of code, and which is, you know, that's a metric that's reasonable. There's a more recent paper, someone threw it at me as like, oh, because I was saying, oh, longer methods are fine. And they were like, okay, well, we have, and I've cited this older book, which most of that research cited in

that book is from the 60s and 70s. So, you know, a little dated. And they sort of threw another essay at me and were like, short methods are better. And I went and actually read the paper, never throw a paper in an academic. Yeah, that I did. And I went and read the paper. And it was like, okay, first of all, this, the paper here, this paper says that methods up to 20 lines, which is much longer than the four to five lines recommended by clean code, are ideal. And then when you look, we actually read in like the statistics, the statistics that they were using, the one that had the least correlation with, with function size was bugs per function. And so, like, that had no correlation with the, with code length. And I was like, that's the only one that matters because the other ones were like change proneness. Well, yeah, like, if you put everything in one method, of course, it's going to be more change prone because it's all there.

Like that doesn't count. There's 10 times as many functions. There's probably going to be less bugs per function, but that doesn't mean there's less bugs. And that's what I, if I wasn't so lazy, I'd go and do the math and like get the data set from these guys and be like, this looks to me like you're saying, that there are fewer bugs per line of code in larger functions. So, you know, and then I also went out in that section. So all this stuff's on the essay's page on htmx.org, it's the code and dirty essay. And I go out and I find in like, you know, Chrome and Redis and like IntelliJ,

like all these big, successful software projects that have very high quality levels. And they all have massive functions in them, like hundreds, you know, like if it's in the high you know, close to 100 lines or more functions in them. And so I just don't, I think, you know, again, I don't want to say you have to have long functions, but I think there's good evidence that long functions are not bad and maybe even good. And I do make one philosophical argument for big functions, which is when functions are big, when your, when your important functions are big, that's a physical, it's an aesthetic, like, hint, like, this is important.

Like, there's no 100 line function that's, not important, right? Like, and if you try and break everything up into like a bunch of five-line functions, you kind of smear the importance around in your code module quite a bit. And I just don't think that's good. If there's code reuse to be found by extracting methods out, then that's, okay, now you've got a reason to do it for sure. But if there isn't, you know, I don't, I just don't think small functions for their own sake is a good approach to writing software. I think there's also, it's just not the way I do it. I think there's also some other, you know, aspects of that too, which is that, like, in a long function, it's easier for the programmer to digest.

Because I can just go, they're just reading it top to bottom and they go, okay, I see exactly what this thing does. I don't have to stop every so often and go look at another function that I might not know exactly what the specifics are, right? Right. And easier to debug. If you have a lot of context, like if you find yourself passing a lot of arguments around with, like, context stuff. like, okay, just make, it's all there and it's fine. You know, yeah, I think that's true, too. I'm sorry, I got to go out of the stupid robe.

That's all solo robe it. It's all right. I can't take mine off. You can't. The other thing that I think. This one, it's okay. No, it's all right. I'm not ready for that.

The other thing, too, I think, is I've noticed this for, like in Golang. It's easy, or it's easy to see when something, like iterates over a list because they don't have fancy ways to like do list iteration on accident right and one of their ideas is like yo if something's expensive you should like put it it like you should make it obvious you'll put it in a loop it does it for all of these things so you're like oh it does it for all the things and i do find for myself when i've done like neovim has a bunch of functions that are like incredibly large some of them i wish they were but like also whatever like it's fine and also neovim i would say is like pretty successful software

whatever right but i see the four loops right i know this thing goes over all the things that's actually like really useful information for me as the programmer and i was like oh that function gets called over all the elements or all of the elements twice right or something like or we have nested four loops and suddenly you're like oh now we really have to be worried about something where if it's like a function or probably not

if you hit the network at any point well yeah that's a separate yes right but the I guess I'd also say

the talking about the change proneness was mentioned I think there's additional things for large functions that speak to that

which is assuming that the code is going to change which is the most important thing to be considering when you're thinking about architecture

Like usually the most important thing for architecture long term is how is it going to handle the fact that we have to change some things, right? Short term architecture, you know, is about does this thing work well at all, right? But long term is does it support us making different decisions because we decide, oh, we really need to do this or, oh, we need to deport to this platform that does some differences or who knows what it is. We want to add these features. And one of the things about large functions is that if you have small functions, every time you make a change to the smaller function, these tiny little functions, you have to be aware, you almost need assistance from your tooling to know who calls that function. Because if you change something about how it behaves, you may be in trouble if there was any possibility of leakage.

And it's very hard to guarantee that you don't have any of that. People who are really into solid and all these things pretend that they're somehow also functional programmers, that there's no side effects, but they never write things that way. The objects are getting changed all the time, right? And so, really, you look at this function, and they're very rarely in like a solid code base or things like that, very rarely are there no side effects in these small functions as well. And as a result, if you have one large function and you just look at all these steps, in the middle of that, you don't really have to ask yourself,

is someone else calling into the middle of this function? Because that's basically impossible, unless you've got labels and long jumps or something crazy going on, right? No one can come in there. You know that they have to start at the top. If you have all these other little tiny things, and that's how this operation's happening. So instead of a thousand-line function,

you have 110-line functions, all of a sudden, for each one of those, you've got to remember, wait, did anyone else use this function for something that I'm about to change? Or should I maybe just leave it and make copy it and make a new function, that's even worse, because now I've got two copies of something

that does something very similar, but I changed one. And so keeping functions large, if there's no other reason to pull the pieces out, is actually important for a lot of reasons, not just because it's easier to read, but also because it may be easier to change and to have confidence in changing as well. You know, easier to test, too,

because it's just, it's that function that you're testing. Now you're not like, oh, wait, okay, crap. I hope we had coverage tests for this test, for this function everywhere else it was used, because I just changed how it worked, blah, blah, blah, blah, blah, right? So I have maybe a little bit different of a reason why I like larger functions is that often when associated with a bunch of small functions, you also have a bunch of kind of inversion of control,

things that are passed in on construction that are like, okay, call with this thing. And so you have this kind of upside-down tree effect that's happening where you jump into a function and it calls four other functions. Like, that's all it does. It's just function A, B, and C, and then you're like, okay, I can kind of get this, but then it's behind a strategy pattern. So you're like, okay, what's the implementer of this thing? Then you jump into the implementer of that thing.

You have to find it. And there's like three different versions of it. Then you go, okay, which are we looking at? We're looking at this one. And you just do this progressive nail, like drill down. And by the time you've hopped across two or three or four functions, I start to forget, like, what was the original function that I was actually in? And so I have a relatively short context window.

I can get about four functions in before I forget what just, like, where was I? How did I get here? And then I'm just like spamming Control O if you're in Vim. and just trying to like hop backwards going okay okay I'm back in I'm back in and then I go forward go forward go forward jump once ago I forgot everything again hold on what was it two like two jumps in because then you just get into this like hopping business I think LSP have made this worse because LSPs have made the navigation of short functions easier which means that those that are very adept at remembering like 19 function calls in a row which I'm just not that person it is very easy for

them to keep on adding because they can navigate super fast. Whereas before, it was probably a little bit harder. You'd have to remember your file. You'd have the fuzzy file find into it. Then you'd have to search for the function and then jump to the function, right? You couldn't as easily do it for every single language under the sun unless if you were in some sort of paid for editor.

And so, but obviously Java being, uh, having a lot of access to that. But nonetheless, I just find that I can't understand small functions well. Like it's just purely a, I lose track of where I was going. and once you throw in strategy pattern, I just lose the game and I have to like debug a whole bunch with print statements because that feels like the only way

I can contain the context because actually step debugging becomes too difficult at that point for me to even like walk through it. Yeah. I'm a different kind of problem with them, so there you go. I totally agree.

I think one thing like I said this on Twitter the other day, like we need to stop pretending that abstraction is cost free. Like it's not. Like whenever you make something abstract, When you slap a clap, like you take an if statement and turn it into dynamic dispatch, which is a joke I made today. Like, anytime you do that, like, there might be good reasons to do it. I'm not saying never do it, but don't pretend that's cost free.

Like, there's a bunch of names you got to remember now. There's a bunch more crap you got to understand, like, just who's doing what? What's the dynamic type? Like, it just gets a lot harder to understand. And good old loops, ifs and loops, you know, say one and will, they do what they do. And they're easy to, they're easy to understand. And so we shouldn't, you know, get intimidated into creating overly complicated solutions to software because, you know, we're just used to this one tool abstraction. So we just whenever there's, whenever stuff starts to look a little ugly, we're like, all right, throw some abstraction at it.

And it just, it can make things significantly worse at times. But it does make the end product look really nice. There's like this moment where you have like four lines of code and it does everything. So I understand kind of that like the purity pursuit of it all where you're just like. like look at those four lines. I'm like set it up, make it run, do a little printing, close gracefully. And I'm like patting myself on the back. I'm like, this is beautiful. And then you just have to do something and that it's horrible. Well, it's worth pointing out that like all of this discussion about long functions is just to support the fact that if you feel like a long function is working

well for you, it probably is. Obviously, there's also, I mean, I write plenty of short functions. So I would never criticize a short function for being short. If this thing, if that's the appropriate length for the function, then great, right? So I think it's more, it's more just like functions take all sizes, right? Like stop fat shaming functions. Beautiful at any size. Beautiful at any size is literally where I'm at on functions. I would point out one more thing because you brought up abstraction.

So I feel like there is a, in the didactic or in the, in the, in the, pedagogical versions of these things, where people are like making these claims. And again, they're never proven. They will say things like, oh, well, the reason it's fine to have all these small functions is you just give them good names, and then you just write the code and the names are there. Now, this is just completely false. And the reason it's completely false is because if that were true, those names would just be the programming language. Right?

If the name could actually capture all of what you actually needed to know to understand how the code behaved, then that would be the programming language. The reason it's not the programming language is because actually every time we give a function, even a five or six line function, a name, we lose some information about what it actually did. some edge case it didn't handle, some bug that was in there, some thing that it's simplifying because we know in this code base we don't need to do that thing. Something is getting left out of that name because the name isn't as long as the function is, right? The function is in the language that's the most concise way we know to represent that, or we'd be using a different language. So when you do that, you're creating, and as you do that level upon level,

you're creating this sort of complete false sense of what the program's actually. actually doing. You read something and your brain thinks that's what this function does, but actually this function does so many other things and doesn't do a bunch of things you were assuming when you read the name. And so that's why that's not a simple answer to this problem. It's fine to do this structure because we do need functional decomposition to program for reuse, for just managing, you know, at some point if the function's 100,000 lines long, that's going to be pretty difficult to manage, right? So we do need functional decomposition and we do need to give them names because that's all we can do as humans. We just, that's how we can like, that's the only way we can abstract a thing is to give it a name. But you have to remember, that's not a solution to these problems. It doesn't solve the problem

of, is there a bug lurking in here? Does it not do something I was thinking? Will this name mislead me into thinking something else was happening? Blah, blah, blah, blah, blah. The name isn't a substitute for the understanding. No matter how good you are, it's not a failure of the programmer that they didn't make a name

that perfectly captured. If you could, you would be the best language designer in the world. So that's just a, you know, that's a given. So I think it's important to eternalize that. Hey, we need to hear from TJ. TJ's been silent sitting in a bathrobe. I think he's actually in a hot tub right now. I can't tell what's happening.

I'm just absorbing all this great info. The thing that I was going to say about to sometimes when you split, and I think you kind of touched a little bit on this prime, but to like expand a little bit more. One thing that becomes really difficult is there's a temptation to smush a bun of somewhat related but not exactly the same like push it under one abstraction and then you pass in like 37 switches to this like top level function and then it's going to like do all the things maybe and like you might even only construct it one way anyways which is kind of funny you

might have accidentally wrote all of these like crazy convoluted option things blah blah blah blah, you literally have one top level caller anyways. That happens quite a bit because you're thinking, I'm going to need this later and then you never do. The company shuts down and you could have shipped six months earlier and maybe your company would have existed. I've never had that happen to me,

except maybe I did. But anyways, like, so sometimes you end up doing this and it would have been much simpler to understand just because you didn't have to pass all of, I think Carson you had mentioned too, like pass all this extra context and everything else inside of the, and switch off of all the conditions.

You just write it top to bottom, and you can see what the control flow looks like. And it's a lot simpler for some of those complex cases to just spell it out for yourself. You know, sometimes an if statement is more than you need. You don't always need polymorphism. You know, like sometimes an if statement is perfectly valid. All right, sometimes an if statement is just an if statement.

It's just an if statement. Just write the if statement, guys. It's all good. All right. So to keep this thing kind of tight, because often we end up discussing for way too long, there is one more. We can't go too long on the stand-up. It's literally the whole- Well, Carson may have to go.

Oh, yeah. No, I'm good. No, we're trying to keep, remember, we're just trying to generally keep episodes to 30 minutes. What? That's not true. I don't want to accidentally be an hour and a half on one topic. Okay, well, I don't know. Me neither.

Okay. Relax. I've got it slotted in for an hour, buddy. You know what the problem is, Prime? You're not in a bathrobe. I feel like I don't have bathrobe mentality right now. You need a bathroom energy. Big bathrobe is coming for 8 Prime.

YouTube, leave a comment if you want this to be an hour. Leave a comment if you want this to be an hour. Yeah. Okay, well, maybe I'm wrong. But the real question I have for you, because you said you don't like unit tests as a means to drive development. My only, I guess, counter for that is that I really like any form of testing that I can drive a feature that I find too complicated to write ones.

meaning that if you just ask me to sum a list of elements, I'm not going to test it. I'm just not going to do that. I'm just going to write a for loop and sum the thing. Like that's what I'm going to do. And so there's a lot of logic I just simply don't test because it is stuff I can write one shot. And if there ends up being a bug in it,

it's pretty straightforward. It's like not something that I need to worry too heavily about. But every now, then you get into these situations where you're just like, okay, this is actually pretty complicated state to transform. And it's also complicated to get running. so I want this to be a unit test. I want to be able to drive the development of this via a unit test,

not because I love TDD or that I'm even writing the test first. I just don't want to have a bad development cycle. And so that's kind of my only defense or against what you said about don't use unit tests is that I just like it for the implementation side when it's too hard. Yeah, it's always dangerous because I don't want to come across as anti-time. I'm a huge fan of testing. No, you're not. You can just admit it.

Okay, Carson. And I think, you know, one thing that's tough here is the language. Like, what's a unit, you know, and like you'll get people that it's just, it means whatever it means anything. Okay, well, everything's unit tests. The nothing's a unit test type situation. It's my whole product. That's one unit. Yeah.

The smallest unit we have is the product. Right. So, you know, these, unfortunately, these things can often devolve into just, like, miscommunication around definitions. which is just, that's the internet. Why else even be here? Honestly, we're not going to argue about terms. We're not going to argue definitions. But I think, like, what I would say is, like, when I say I'm not a huge fan of TDE and

unit tests, I mean it in the sort of the original sense that you were talking about, which is I'm writing a solution to a problem, and I'm going to, like, write one method, and then I'm going to exhaustively test that method. And then I'm going to write another method, and I'm going to exhaustively test that method. And then I'm going to eventually get to, like, okay, now I've got my solution, because every method does exactly what I expect. And then maybe I'll maybe write some what I would call integration test, which is like calling the more high-level methods that maybe invoke three or four things,

or if you're a fan of larger functions, a function that does quite a bit. There's not really a unit, you know, and at least in my opinion, given the way it's typically used by TDD advocates. So what I prefer to do is, like, and I think this is kind of getting at what you're talking about, which is, and so much of this depends on where you are in the software development cycle. Like when you're first starting out, you have no idea what the solution is typically. If it's like a new feature, you just don't have any idea. You don't understand the concepts. You don't understand what the domain looks like.

You don't understand what the API should look like. And so you need to like play around and like find like what's the core ideas here. And then so, you know, in my Grubbrain essay, I call that a cut point. Like you find like, okay, here's the API. Like this is the API. This is what this thing is going to do. And then I would say exhaustively test that, which is getting what you're talking about, Prime where it's like, okay, I really need to like hammer this down. But I'm not going to look at the functions and test every individual function necessarily. Instead, I'm going to focus on the higher level, what I would call these integration tests. I'm going to focus on the higher level API for this system. And then I'm going to exhaustively test that. I'm going to try and get all the corner cases as best I can when I'm doing that. And so that's one of There are times when TDD makes sense. Like if you're going in and adding like a really small feature to a huge like existing code base, okay, like is there an existing set of unit tests? Yes.

Okay. Then do a unit test for that one small piece of functionality. And if there isn't unit tests for it, like maybe you need to go back and add these integration tests before you add that feature so you're sure you're not screwing things up. So it's just that I guess and this gets back to what we sort of said at the start. start, which is like there's this ideological, ideological approach to coding. It's like, do this. And it's like, no, like, so many things are situational. I know no one wants to hear it depends, but it does. It depends on stuff. Like, if you go into a code, like, okay, you know, object oriented programming versus functional programming. Well, if I go into a functional code base, I'm not going to

impose object oriented programming on top of it. I'm going to be a functional programmer. And vice versa. Like, you know, you got to vibe match the code base, if there's a lot of code, or you're going to be a wreck and you're going to make things worse. So so much of this advice is, that's, I guess, like, my big meta point here is, like, there's a lot of advice that's, like, not bad in, you know, in a lot of cases, but it's just too ideological and it's too easy to overapply it. It may also put the focus in the wrong place. That's often what I say about auditory into programming, for example, is I'm like, you

may end up with objects as you are programming because that's the natural, like, you'll find natural places where those things occur. the problem with the way that it's taught, at least in my opinion, is that you end up in situations where programmers, I see this. Programs are hyper-focused on needing to create objects. It's like it's now become an activity in their head that is like the end in and of itself. But that's like objects for objects sake don't do anything for you, right? They only make sense if they take on a particular structure that is beneficial to the code base. And so it's one of those things where you're just like, look, the problem,

is the focus sometimes. The problem is, it's like we were saying, maybe it is good advice to have, sometimes this function was too long. We should break it into smaller functions. That could be very true. It could also be very false. The point is to learn what the metrics are is

do you want this thing at this time? That's part of learning to be a good programmer. And anyone who says, oh, it's just this rule is usually wrong, right? Unless there's something that's so bad we can tell you don't ever do this one thing, right? But, you know, Do not nest ternary statements.

Yeah, even I don't nest ternary statements, and I like ternary statements. I do too. That's probably a safe one to say. That's a safe one. There's always one, and that is the safe one, and also don't use repeat-at-tale. Repeat-tills the devil's loop. Do while the Lord's loop, okay? It's very, very obvious.

I was going to say I just had one quibble with Casey's thing of saying, like, you know, creating objects for object's sake doesn't do anything. it does give you a chance to make significant performance improvements in Q2. So that's like you've got to be thinking a little bit bigger, Casey. Like there's, you've got to be thinking, oh, I could remove these objects later. Okay. Oh, baby, speed up. Here we come.

I see. You got the plan for what you're doing when you're on vacation. Exactly. This is Silicon Valley mindset right there. You are not bathrobe maxing like me, Casey. You can't possibly understand, but that's okay. Yep. All right.

Yeah. Fair enough. To be also to kind of double click on yours, Carson, with this whole unit versus all this. I use the term unit, but really in my head there's only actually two sides. There's end to end. Like I actually start up the whole program and kind of black box the entire thing. Or I'm trying to unit test some easy startup and go, and I just call that a unit. Despite it not being like literally just a function, it could be many functions.

It could be a function that calls many functions. And I, you know what? This whole idea of having, I don't know. know the difference between like functional integration. I don't know when unit becomes functional and when functional becomes integration and when integration becomes end-to-end tests. I just like the idea of there's there's the whole thing and then there's just like some discrete unit and that's it. Yeah, you use the difference in the terms whenever you want to make your opponents, things look bad, right? Exactly. That's what's incuriating.

See, what you were writing there, that's a functional test. Man, real unit testing hasn't been tried. Yeah, and so you can get them with that and you'll instantly win. Like, you're once again, you're not bathrobe maxing on this, Brian. Maybe that's my problem is that I haven't lived the bathrobe life. And once I do, so many new parts my mind will open up. It's kind of like taking LSD for the first time, except without all the consequences. It's just all the mind opening experience.

I'll just have a bathrobe opening experience. That's all I ask. This is as close as I get to LSD. Yeah, I do one thing I would, you know, I should say about end-to-end tests. I love end-to-end tests and they're really important, but that's an area where you have to be super disciplined about not overdoing end-to-end tests. I've been in multiple companies where we just, our end-to-end test suite got too big. And the Grug Brain essay, there's a section on testing.

And I mentioned that. Like, don't over, you need to have, you need to have an end-to-end test suite, but that needs to be like religiously maintained. and it has to focus on the most important things in your app because if you add too many, they become non-deterministic and then they start breaking and people stop paying attention to them and they're absolutely like the best canary in the coal mine you can have.

So like that there's that balance. You know, people are like, oh, end-end tests are good. Let's have more of them. And it's like, no, no, you got to be balanced about this stuff. You can't, you can't overdo your end-end test suite or it becomes less valuable, you know. And it's just one of those, you know, weird things you just got to figure out.

And they're also disproportionately harder, or they're disproportionately harder when it comes to any sort of like data or service refactor. Like any of those, it's just like, it's a lot more work to get anything done. Yeah.

Like when you've got a big system refactor, they can be absolutely crucial to like, okay, we didn't break the whole system. But if you have too many of them or if you don't have enough of them, it's just tough balance, you know?

Or you're testing the wrong, the wrong outputs too. It's really easy to be like, oh, I'm going to assert 75 things about internal state when we get done. And you're like, oh, now you really are locked into that. It's going to be very hard to like make a change and assert the behavior is the same. Because it's not clear which thing is actually like behavior versus random stuff you kept at the end of of your thing.

This is one of the things that like I see a lot why I get really annoyed with like AI generated tests. is they like, at least from all the ones that I've seen people do, both in demos and in practice, is like they really assert a lot about the internal state of things and are tightly coupled to the integration. And it's like, dude, if you ever want to change anything, all your tests will break every single time. Like you won't get any of the good feelings of knowing the system still works

because you broke everything every time you change them. That's kind of unfortunate because AI should be like, AI should be leading the way in not doing that. It's like, dude, you've got something that can literally parse the screen visually. Why are you testing internal state instead of looking to see whether the program produced the correct, even graphical output if you wanted to, that would be an incredibly beneficial feature, right? So it's like you would want AI hopefully, I assume we'll get there or someone already has, but just not widespread, to get to the point where the AI testing is actually really helpful. You can just be like, oh, here's what the program looks like when we run it normally, right? And remember that.

And tell me if it ever stops doing this, right? You know, like, tell me. And then, you know, hopefully it can do that at some point pretty well, right? Yeah, there are some cool solutions to that that I've used before, but they're not like AI. They do other stuff for it mostly. Yeah, I mean, we've had things like OCR and edge detection, things like. So it's like, it's not that you couldn't do graphical testing before, but it's like this would make it a lot faster for people. to create. They could create anything.

In games, we have this problem a lot where it's like, how do you make tests for the end product? Because it's kind of hard to know what it should look like. Well, an AI could easily do things like play the game, find some things, look at things. Oh, that object fell off. It's not supposed to fall off that thing.

I could imagine things like that that were very hard to create tests for before that maybe AI could help with. I mean, I can't say for sure that it will, but it could, right? Yeah. I do think the thing, it's hard. because like business, I don't know, constraints and outcomes can change,

but it is kind of nice if you write like a test that is associated with the actual like business out, business logic outcome that you want. Because then if that changes, then it's okay to delete the test, right? You know for sure, like, oh, we were supposed to calculate tax on this and then the rules change and we aren't.

You're like, yeah, cool. Okay, well, then I need to delete the test because it's lying now. Like, that's good. And I think a lot of times people don't actually test kind of like the requirements or the constraints of the system. They just test like whatever pops into their mind or like random boundary points. You know, that's another important point that and I make it's not in the Greg Brain essay, but it's in the code and dirty essay. Like test suites, they take on their own mass.

And like if you have too many tests, like you got to be careful with it. because the tests sort of force you to, you're committed, and it's like, I can't make this change because I'm going to just break a bunch of crap. And so that's why, like I say, like, sometimes it's better just throw the unit tests away and keep the high level tests. Like, tests at the highest level you can get away with because the higher level those tests are, the longer those invariance about the system stay true. And then you have flexibility at a lower level. If you've got a thousand unit tests for every single function in some, you know, code module, like you're not going to change it. You're just not. It's just this it leans on you in a way that, you know, people, I think, don't appreciate. And again, this is something where, like, testing is good, but too much of it can be bad and doing it, you know.

And so I think you have to be really careful with these things. It gets back to a cost-benefit analysis. The reason that tests, the only reason tests can be good is if they benefit you more than they cost, right? They're making, you know, less bugs show up in production that were harder to find, or they're preventing some catastrophic thing from happening, or they're making development quicker because you don't have as many bugs during development, whatever it is. If you go too far, the cost of the tests starts outweighing the cost of the bugs that you are finding, right? And so when you've hit that point, now you're just doing bad engineering, right? Making the project cost more because you were testing it is not a plus if it doesn't actually produce more reliable software at the end.

So you have to make sure you're hitting that. You're hitting that programmer time is zero sum. is the way to say it. Time they're spent writing tests is not time they're spent writing the code. If you've got that cost-benefit trade-off incorrect, you're actually hurting the project not helping it. So you have to be intelligent about where you put your tests, how you write them, just like you do for regular code. You have to have a good idea, a good sense of what should be taking your time and what shouldn't be, right? To be completely fair, you know, crowd strike really tested all of their stuff. Yeah.

They had a lot of tests. They had many, many tests. But they managed to turn off the world for like a week. And so that was a real thing. So it just, you know, not all tests are valuable. Yeah. And I think you mentioned this when we had our episode on testing, Prime. You were like, you know, shipped to a very small number of people and be very careful about that as you staged rollouts, right?

And like, the crowd strike is why. It's like, look, the slower you can roll these things out, which in their case, I guess they just didn't. feel like they could do it any slower because it's you know it's you're trying to stay ahead of zero day stuff or whatever but the slower you can roll things out the easier it is for you to get those canaries early and not ruin 100% of your users lives by something you didn't catch right yeah and i think a really good thing to always remember is that tests catch bugs that are known they're not a blanket for catching things that do not that you do not know about yeah things things that are that are too subtle for you to have thought of you may just well not catch in a

test because you didn't think to check for that, right? Yeah, exactly. They only test for things that have been discovered. There's still plenty of them lurking about that you just haven't figured out yet. Hey, so, Carson, you are kind of known as a meme master. Okay? In fact, I've heard that every time you have a meme that doesn't hit great on Twitter, you whisper to a mutual friend of ours.

What? A quotation from Jesus, which is, I believe Jesus. It could be, hey, it could be, it could be Solomon, but that you say that you do not throw your pearls before the swine, because they just did not quite, they did not quite get the meme, and the meme was not good enough. And so you were a meme master. Yeah. Well, no, I don't agree with that, but I do make memes. Don't even lie to me. We've already talked about this.

You've already said that the only time you're super serious is when you're about to make a joke. It's time. It's time to be super serious to make this joke. He sent you those in confidence, Brian. Okay, maybe I'm that friend. Maybe I'm the mutual. You should have known better, Carson. He's literally known as the leakage.

Maybe I did know better, T. Maybe I did know better. Yeah, maybe this is a 40-chess move, T.J. Yeah. I'm just trying to sell Greg Brain books, man. That's all I'm doing here. Here's the deal, T.J. Yeah.

Oh, well, yeah. DJ, what was that? Oh, you don't have the latest. D.J., I figured you wouldn't. Not a big deal. There's an updated version of of this? There's a soft cover, which is, I got a sweet cover. It's like this pixel art like thing.

Everyone buy hypermedia.Systems. And then go to gorgbrain.com.combein.combeen. And then go to gregorne.combeen let's do a quick little, uh, plug for that, actually. So Carson, tell us about this book. I'm interested now. I didn't know about it. Um, so hypermedia system, you can go to hypermedia.

And you can read it online for free. And then there's a hardcover and a soft cover. They're different covers. The hard cover was done by, uh, uh, it's now US graphics. It was Berkeley graphics at the time. Makes the best fonts. The best fonts. Yeah, he makes awesome fonts. Shout out Berkeley Mono. Yeah. Yeah. Berkeley mono is really good. Um, and, uh, so, uh, there's that and then the soft cover prime hold that one up. That one's really good too. Do you have that? Yeah, yeah. I have that one. It's, it might, it's mirroed right now. But it's like, it's blurry. I'd have to go manually adjust it. Yeah, but that's pretty cool. Um, and then you can, so anyways,

It's a book basically on HT, it's, it's, it's three sections, and it's basically, you know, HTMLX is sort of hypermedia oriented. And so, like, the first section is like, hey, kids, here's how the web actually works. Okay, okay. Here's how hypermedia actually worked, like back. Like, it's a web 1.0 style app, and we build that out. And then the middle chapters are like, okay, we've done that. Like, let's make it better with HTMLX.

Let's improve it sort of incrementally with HtmX, which is building on the same idea as sort of the hypermedia, you know, fundamentals of the web, I guess is what I'd say. And then, and then the last section is on a mobile hypermedia called Hyperview, which is, this guy Adam Stepinski, I'm good friends with, he built a mobile hyper media system, basically. And so that kind of is like, like, hey, just to show that hypermedia isn't only about the web, like here's a cool thing that, So the nice thing about Hyperview is like you don't have to update your, you don't have to update your mobile app on the app store to get an update out to your users. It sort of leverages the same deployment model that the web does. And who would you say is the best target audience for the book?

I think it's, I wrote it for younger web developers, like people who, but I think a lot of, you know, to be honest, like a lot of the older guys like it because it's like, oh, I remember this. This is cool. But it was sort of written for the younger developers who came of age in the last decade when it's just like, here's React. And like all it is is like React and JSON APIs. And that's what you're used to. And so you don't have this like sort of background in like how the web was designed and how hypermedia. Like what is hypermedia? What's special about it?

Like why was the web so effective in growing as a distributed system versus other distributed systems? And a lot of that boils down to what is called the uniform. interface of the web. And so you can read the book and there's some essays too about it. All right. I'd say it's like I read it it's 2025.

What Carson that had to be like a year and a half ago. It was just right when I started talking about HTMLX first time. And I thought it was awesome. Like it's very interesting to think about a bunch of different options that you have like out in the web. And then it was cool because I just didn't want to write JavaScript all the time. So it was fun. to explore using HTMLX, like, with different backend languages, and then you could still have a website that didn't reload the whole page anytime you wanted to do something, which is, like, terrible U.S.

And it's sad that browsers haven't found a way to give people that tool separately. Yeah. All right. So as a meme master, the reason why I said that is because I believe Casey ran into a bit of trouble. Yeah. So I wanted to talk to you guys about this. And I didn't know Carson was going to be on, nor did I know that he was a meme master. So this turns out to be extra appropriate that we're doing it today.

But it's just something that I know, at least like Prime and Teage, I already knew you guys. I mean, you're out there on the social media. You know how to get the crowd engaged in a meme. I get a lot of likes on the facebook.com. I mean, you're all over the facebook.com. The MySpace, some of these up and coming. platform. Way more than five friends. So I felt like it was a good time

to talk about a personal experience that I had. Please tell me it's bird sex. Birdsex spiral. Sadly, you know, I wish that it was. I wish that it was, but unfortunately it wasn't. And I want you to sort of cast your mind back quite some time

to sort of the era when I don't want to say a bad thing about Microsoft. But obviously as the web was sort of ascendant, you had Fang. You noticed the F-A-A-A-N-G acronym was there. There's no M in that acronym, right? Correct. Microsoft was not the hotness.

The web was taking over. They were kind of considered this older player that's not that relevant anymore. Like, if anything, I just use Windows to launch a browser, right? And so they had to start becoming cool because all of the new recruits, all of the summer interns who are coming out of college who people were trying to hire, they're all going to Google, they're all going to Amazon, they're all going to Apple, they're not going to Microsoft, right? So back in the day, and this is maybe five or six years ago, I think, right?

Back in the day, for some unknown reason, probably driven by this situation I was just talking about, they one of their recruiters went ahead and sent this memo and I'm posting it to Twitter right now as promised prime oh I was hoping you're going to put on your screen I made you full screen for this moment no no no no this is going to go out for everybody you can do this prime in fact what's your Twitter account it's it's C Muratory C M-U-R-A-T-O-R-I and I will read you what this said this is the the email that one of their recruiters sent to all of the interns. And it says, hey, Bay intern, B-A-E, right? And it's got the little, yeah, that's the opening of the, of the email, okay? Says, hey, Bay intern, and it has a little, it's got the party hat with the little testicles. I don't know what that emoji is supposed to be. It's like a less than followed by a three.

Oh, that's a heart sign. It's not a testicle. Oh, it's a testicle. I mean, when I see that, I see testicles with a party hat on, but fine. It's a heart. Hey, Bay intern, right? That's what she opened with, I guess, or I guess I don't know anything about this recruiter, but he or she, we'll say they, because Kim, I actually know a guy named Kim, so, you know, I don't know exactly who the recruiter was. It says, hi, I am Kim, a Microsoft University recruiter. My crew is coming down from our HQ in Seattle to hang with you and the crowd of Bay Area interns at Internapalooza on 7-Eleven. But more importantly, in green underlined text, we're throwing an exclusive party the night of the event at our San Francisco office and you're invited. And here's the money part right here. There will be Helenoms, lots of drinks, D-R-A-N-K-S, the best beats. And just like last year, we're breaking out of the yammer beer pong.

We're breaking out the yammer beer pong tables. The closing line is, all caps in orange for some reason, Scroll down. Hell yes to getting lit on a Monday night. Okay, so you got, do you have the idea now? Do you see what I'm talking about? Time, let's throw this party, dude. I think we know who really tight.

I think we should throw this party. Not only should we do this party in San Francisco, but I, dude, I know. Five stand-up episode. I know. I think we should do this. But on top of it, you know that meme where it's the scientist holding up a green vial, and it's just like I have distilled peer cringe? Yeah.

This is what I'm currently experiencing right now. There are people in the chat that don't think that this came directly from Bill Gates, and it's just incredibly disappointing to me. If you've done Bill Gates didn't write this, you're out of your mind. He wasn't there anymore. Here we go. He's a shadow right. He's a guy.

Listen to this guy. This is Bill Gates. This is classic Bill Gates. All right. All right. Yeah, it's quote unquote Kim, but we all know it's Bill Gates. G secretly. Yeah, where's the metadata on this email?

Did it, is there like eventually from Bill G at Microsoft? Yeah, we need a Freedom of Information Act situation here. So I saw this. I saw before the meme. Yes, okay, go ahead. We should throw this party in San Francisco and do a live episode. Developers, developers, developers, developers, developers. Did you see my recent one?

I've reenacted that, Carson. Did you? Are you serious? I see it. I did not see that. He went very, very deep on this. he we'll play it at the end yeah yeah yeah please i want to see that i don't i want to hear your meme okay yeah we'll do one meme at a time yeah one meme that's exactly smart smart smart smart smart so

so here's and i'm just going to tell you what happened and then like i said what i'd like is for you guys to explain to me why did i screw up this meme i felt like this should have been a slam dunk okay and i totally and no one cared i posted this on twitter no one gave beautiful this is so good Okay. So here's what I thought to myself. I'm like, okay, hell yes to getting lit on a Monday night has got to be a meme. Like that's got to be a meme. How does that not become a meme? So what I did, and this is obviously in the era before AI image generation. So I'm loading up, you know, an image editing package. And I go and I find a picture of Satcha Nadella, who's the CEO at the time. So he's already taken over at this point. It's not Steve Bomber. He's already gone. So I find a picture of... Dude, RIPP, Jack Johnson. That's all I got to say. Jack Johnson?

Sorry, keep going. Okay. Sorry. Separate meme. Okay. So I find a picture of Satchanadella giving a lecture, like giving one of his presentations as CEO. Where his hands, I like look for one where the hands are already in a position where I think it could be holding, like, one really big water bomb. Right?

I just look for something that's like close to that. I know I'm going to have to move the hands a little, but I want something pretty close to him holding like something real big and like he's getting really lit on Monday night. He's not like slightly getting a little toast. He's like going all the way. Okay. I do that.

I find this, I find the craziest water bug I can. That's got the, that's positioned like it's rotated such that it was. go to his mouth correctly. Right? I Photoshop those two together. I even, I like comp the lighting, right?

I work in computer graphics. So I'm like, so I comp the lighting. I try the shadowing, right? I get this big old smoke plume. Like, so it's just cover it. Like, it's just, he is hitting this thing hard on stage. And I'm like, this is the greatest meme ever. Everyone's going to love it.

I post it and no one can. cared. And here it is. I'm putting it in the reply. Okay. Yes. Put in the reply. And what did I do wrong? I'm pulling it up right now. I'm pulling it up right now. Where did you post it? Did you quote? How did you send this meme originally, Casey? I don't know. We'd have to go back and look. All right. Hold on. It's so good, though. It is really good, Casey. I'm pretty sure if I just took the meme right now, I would get a thousand likes on it. Yeah, just steal it. Steal it. Steal it. Copy paste that to a brand new. There you go. I've already posted it. I've already posted it. A brand new tweet. Blow it up, boys. Yep. I'm doing it too. Blow it up. Yeah, I think you maybe overcooked it a little bit. That's what I was thinking, too. I was

like, did I go too far? The image is too. You need to JPEGify it a little bit more. That's actually the problem, I think. It's such a good image, by the way. Like, you really? And by the way, you did call this a beer bong. That's just an old-fashioned bong. Water bong. I call it a water bong. It's a water pipe.

Oh, sorry, water pipe. I went to Berkeley. He knows all about this. I've always heard them referred to as water bongs, but I don't know. So I'm not the next thing. I have the way that this could have been a huge, a huge meme for you. Okay. And there's still time because no one knows why Prime is posting this one.

Take the original image and put it over top at like 50% opacity. Right? The original text that's saying, hey bay interns. Okay. Okay. And then. Hey bay interns is pretty good. I think you can do all right.

You got a good because they're from the Bay area, but it's spelled like the other kind of bay, dude, it's so good. I don't know about that stuff. Because I feel like if that's, if you've got the overlay, that's a, if, if, if, It's going to do 100,000 likes. I don't know about that, but it's worth reshooting. Send it out tomorrow. We'll juice it in the algorithm.

So we'll try some different approaches to this meme, see if we can get it to latch. Okay. Yeah, exactly. Hopefully people listening back to this later have already seen the meme before they hear it in the statement. But now that would be cool. All right. So I do want to throw this out here. I think something else is that this meme, I personally look at it.

And I say that its quality is in a reply, not in a standalone. Yeah. If that email was like leaked and it was out and then you replied to it with this, I think that it could ratio the original one just because it's so hilarious. And so I think the power in this one is more in the reply than it is in of itself. Okay. Okay. Quote, quote, quote tweeting or whatever is very effective.

Very powerful. Because it's like a one, two. I think also like the, you know, the meme picks the man. The man doesn't pick the meme. Like sometimes it happens and sometimes it doesn't. And like, you just, you know, you just don't throw your pearls before the swine. That's all you got to say. Yeah.

You just got to do it. I mean, I've had so many fall flat. Like, it's like, just delete them and pretend they didn't happen. If they didn't get a lot of views, nobody even know. Or leave them and just sit with it and get used to being cringy. Yeah, that's true to embrace the cringe. I'm wearing a bathrobe. so what are you going to do?

Casey, did you say a two, though, or did you just have one? There's just that one. That was the only time that I really felt like I was like, I'm going to try and make a meme, and then it got nothing. It's a great job. I spent hours on memes that, like, get 10 likes, and then I'll just, like, say, like, something stupid

to in reply to someone, and it gets a thought. Like, you can't go attention to that stuff. Yeah, you got to keep shooting. You got to keep shooting. There is something to be said, though, that every, I'd say like every 10 minutes you spend on a meme, I do think it goes down and it's quality. Yeah, you can be right.

There's something about that, like, because the reason why you saw the meme and you thought it was funny to begin with is because there's something that turned in you and just like was like, oh, that's funny. And so you have to, like Twitter, you only get about that amount of time for someone to like or dislike it. That's why I never think about what I'm going to tweet before. And I have zero scheduled tweets.

I've never scheduled a tweet. The moment it happens, I'm like, that's the time. To be fair though, Brian. we did spend a lot of time and then rent a yacht to make a music video. That's not always true. That's a different piece of media. That's a YouTube video. That's not a tweet.

It is a meme, but it's a different kind of meme. It's a different kind of consumable meme. So when it comes to Twitter, I truly believe that it dictates a lot. Yeah. I believe that the best memes come from your heart or Twitch chat. They do not come from your brain. The medium is the meme, says Marshall McLuhan. The medium informs the message.

is the medium informs the message. True for a lot of things as well. It's why your tweet's probably not going to change anybody's mind about anything. So play to your audience and have fun instead. Real life advice. Sorry. That was really good advice. I don't know if that's like accepted around here.

Yeah, sorry. We're deep in the standup by now, so it's okay. Just play from one minute 20 on the thing that I send in chat so that they can see the Steve Balmer situation. It'd be best if you could get audio in for Casey and Carson. I know the audio by heart Okay, well, so then it's very important that you can hear my audio. Okay, okay.

Because I studied. Who said sit down? That's my favorite part. Did you do that? I didn't do that part. Oh, TJ. Sorry, sorry, I didn't. He's very angry that someone sat down in the audience.

Have you seen his retirement one? Yeah, Prime, it's one minute 20 into this one. Okay, a minute 20 are still on Steve Jobs. I know. I want him to see the Steve Jobs thing and then the transition in. Well, the problem is that I can't get audio for them to listen to in Riverside. Okay, well, just here. Post it on Twitter and I'll go click on it so I can watch.

Okay, here, it's in chat. It's in chat. Yeah, there you go. You can see it in chat here. I'll jump out and I'll play it on screen and people will be able to hear it. It's just you won't be able to hear it in. Just give Casey a countdown for when he should start at 120. I can't, I, what chat?

There's no, it's not in the chat. Oh, sorry. Twitch chat, loser. I'm on Twitch, Casey. I'm, I'm 48. I don't have a Twitch chat. What even does that mean? No one knows what that means.

Here, Casey, I sent it in studio chat too. I accidentally streamed on Twitch once for like 30 seconds. There you go. How do you accidentally stream on Twitch? All right. You do it all the time, dude. I signed in with Twitch and then I hit start streaming. I didn't know what happened.

I'm still worried Prime is going to leak several meetings. Like he's going to leave stream on all day. We had it happen last week. Fortunately, Twitch chat messaged me in my chat, and I happened to have it open on my side thing. And I saw that they were like, yo, Prime is still live. We can hear your meeting.

I know. I'm going to, that's a bad situation. That's a bad situation. All right, everyone, be quiet. I'm going to start it in three, two, one. I'm going to pass it over to our CTO, Stige Baltimore for more information. Take it away, Steech.

Is someone leaking it or is it just me? There was an echo. Meet your mic, TJ. Was it me? Maybe I was listening to you. Go again. Go again. Oh, wow.

I'm going to have to toughen up. Here we go. What's the $64,000 question for the field? What is the most asked question? I love the bend. I love the bending over. What the beans are we going to do about coffee, Steege? It's a very good question.

And it's got a very, very, very very clear answer developers the key to coffee the key to industry transformation the key to SSH is developers developers developers so much easier to not like hate these guys now developers developers developers develop oh wow this is really well done so yep oh no oh no I got DMCA aid. Yeah, you should have known. You should have known better prime. So here's the thing, you still have the opportunity to do Who Said Sit Down, because that's the one where he runs out on stage. It's not that, it's a different one than the developers one. So there could be a second, Steve Balmer with the Who Said Sit Down with get on your feet. I'll try. We can release another one. Yeah,

yeah. Guys, I tried. I actually dumped water all over that shirt and everything. I also, like, rode really hard for a while before doing it too, but the shirt was just like, like getting translucent. It wasn't turning dark blue. So it wasn't really working. It was showing more than I wanted to show, if you guys know what I mean on that. So it kind of dried out a little bit,

but I tried. I did dump water on it. It just wasn't the look we were going for. Yeah. Yeah, it was the wrong kind of material. It was pretty good mime. I feel it was pretty good. It was pretty good copying of his movements, right?

The bending over the very, like, he has a very sort of a primal stance that he, you know, I'm not joking you. Like, I seriously watched it at least 30 times in a row before I was doing, like, whole thing through, get the whole thing down. I was dedicated. Yeah. It's a very, very good work. Just further proof that cringe is like, for lack of a better word, is good.

It's good. And eternal, you know, like, it's good, man. It's just, yeah. No one, you know, a thousand years from now, no one's going to remember you're like, super hip post, but they're going to be playing the bomber. You know, I hope so, dude. If I could be immortalized as a Steve Baldwin impersonator, that would be so sick. It would really be the end all be all of everything.

Yeah. I think they don't know. I started streaming so that I could do that, you know, like. I think one thing that people forget is that when it comes to being cringed, like, if you just embrace it, it's just, it somehow becomes less and less cringy. Like, even when, like, because, like, when you. can get other people to cringe. I mean, that's the entire show of the office. It's just you cringing incredibly hard at Michael Scott. Like there's some episodes that are like so painful to watch.

Or what's that one that we're watching just recently? It's, I think it's time for you to leave. Yeah, yeah, yeah, yeah. Just the entire time you're just sitting there like, I feel so deeply uncomfortable. And that's just because it's just this amazing, just the cringe is amazing. I know. Well, I think there's like, you got to have solidarity. Like, Chris cringe, we cringy, types have to have solid, like, there's, there's a quote from Chesterton that's like, the comedy of man survives the tragedy of man. And it's just like every person, no matter how cringy they are. And like, you know, it's like there's a human being there. And like, it's all good. We're all trying to figure it out. Like, and it can be really funny. Like, when someone just

goes ape, you're like, dude, yeah, man, that's pretty funny. And like, it doesn't have to be, I feel like a lot of that, that attitude of like, cringe, it's just like, just like, just, you know, You know, this is just another person trying to figure it out. It's all good. I feel like that's the end right there. That's perfect. That's the closer. We'll see you guys later.

Yeah, hey, good standup. No blockers for me this week. Check out hypermedia systems. Yeah. Oh, Gregbrain. Buy the book. Yeah. Clean code, I'm indifferent towards.

But you don't read it to know what he says, though. It's still a good read, even if you don't agree with everything. Thanks Uncle Bob for the bathroom. And I have to say he did mention, he was like, oh, because I was like, oh, it's too ideological. He's like at the start, I say this is the way I do things. And in fairness to him, I'd never read the introduction because I never read introductions. But he does say in the introduction, like, hey, this is the way that I code. And like, there are other people to disagree with it.

So I have to give in that much. I tend to like I'll read. Prom. Motivated if you can read forward, let alone five, dude. I could read a forward. I mean, I've done it before. I can't, I can't give you this like a percentage. But I know I've read forwards before.

Well, if you buy uncle. Bob's new book, We Programmers. You can read my foreword that I threw in there. Okay. Threw in there like you just like a YouTube comment. Just get it through it there like a YouTube comment. He wrote it for real and it's good. I've read both.

It's good. Yeah. Yeah. Yeah. Well, Carson, thanks for joining us today. It was awesome. Yeah, absolutely. I'll be checking out your book for sure.

Uncle Bob on the standup would break the internet. It may happen at some point. Yeah. Give me an Uncle Bob on here. Let's go. All right. I'll sit that one out. You guys could have my slot.

All right. Hey, thank you, everybody, for being a part of the stand-up. The stand-up, episode seven. Hey, if you're still around at this point, I want you to say something sufficiently stupid.