0:00Welcome everybody to the standup. Today we have one of the most fantastic ideas ever, which is you guys have heard of tier list, right? You you you young kids love tier list, right? Well, we got a tier list for the ages, which is all of the programming laws that you run into every single day and we are going to tier list them all out.
0:19TJ, you never interrupted me once. I kept like anticipating it was gonna happen.
0:25He's on the beach. He's on the beach. He's too he's he's in vacation mode, so he's not he doesn't have his interruption skills. He's too laidback.
0:38I got Miami teach today. Okay. Okay. My bad. I didn't realize that. I didn't realize that.
0:43All right. So, we should start with Conway's law.
0:47I'm just in the middle. I'm just going to set it in the middle.
0:52I don't even I don't even want to hear about it. S tier. When we do every law though, Prime, can you read a definition for the audience so that they can also be educated? They may not know the names of all.
1:01I actually have them all right here. I was just trying to find it. All right.
1:04So, let's start with Conway's law, which is uh by the way, legendary game programmer Casey already has an opinion on this one. Sier, which is organizations which design systems in a broad sense used here are constrained to produce designs which are copies of the communication structures of these organizations. Meaning that if you had say a team that runs checkout, a team that runs shopping, you very well may have two different user representations, some sort of weird glue code, like all
1:33sorts of funny things end up happening because each organization runs independently, thus creating their own worldview.
1:39I can give an even better example, which is say you're a co-hosting platform. You get purchased and then you get put underneath the AI division.
1:49At the company. And now suddenly code hosting goes down all the time.
1:54No, that's T's law. We had the same thing on the episode. That's T's law. That's not Conway's law. Conway doesn't say that.
2:01The part about it is that the only thing that matters in the structure of the code is getting co-pilot into everything is my that's not Conway's law. That's teacher's law.
2:11Did I misunderstand it again? Teachers representation of your structure and communication is the representation of the code.
2:19Yeah. Casey Conway's law is a statement about the efficiency of information movement. It basically says that not from the code if you it's like inside a person's head is the fastest information efficiency because they don't have to spend any time to know something they already know. Talking between two people is a little bit slower. Talking between two orgs much slower. Talking between two companies very slow. Right.
2:44Yeah. And so you expect every time you put in one of those bigger barriers that the product evolution will evolve faster where it doesn't have to cross a boundary to do that evolution because the information transfer will be slower.
2:59Um so that's what Conway's law actually says and it doesn't really have anything to do with org charts even. It's just org chart is an example of something that would have these properties.
3:10Okay. I was always led to believe I mean because I I did accidentally state it right which is that checkout and shopping would have two different kind of shapes of data and then they have a synchronization communication layer. So really what you're trying to say is that microervices are just an extension of Conway's law.
3:26Yeah. Micro friends. Absolutely.
3:28Yeah. The way I see it like it eventually bubbles up like if it's an actual like userfacing app it bubbles up to just like it just looks completely different.
3:37Like on UI as well. So it's like you like Spotify the the bar at the bottom that shows like the metadata on the on the song is completely different than the sidebar that's like showing all that stuff. And I'm like for some reason it's so hard to get right and people get around this with component systems and stuff but it's still impossible.
3:55[laughter] So in other words, microrends, all these other things are not programming designed to make your life easier, but programming in which just tries to make Conway's cost go down.
4:08There's a lot of programming practices that are just like really just manifestations of Conway's law. There's several S tier. I'm in Sier.
4:15It's absolutely S tier. Yeah.
4:16Yep. It's also that this is uh as a like this would be also why a lot of stuff where it makes sense maybe for Google to do it in the makes sense sort of way.
4:26we'll say like makes sense cuz they have a million engineers but for everybody else you'd be like no you shouldn't just copy that because you don't have the same cost you just that like can talk to the guy who's programming checkout he's right next to you instead of like build an entire micros service architecture to talk to checkout right that's what I that's yes that's it makes sense in big orgs why things end up being so weird I mean if if for those that haven't worked in multi00 person engineering orgs it's just chaos like you don't even
4:56know what's going on. [laughter] Like you can't you can't possibly know what's going on.
5:00Yeah. I mean that's why you do the micro front end or whatever architecture so your blast radius is isolated to your own product and you can ship at your own pace basically.
5:09I would also just point out that Conway's law is probably durable even into the age of AI because you will probably see as we start to study it more manifestations of Conway's law with agents. It's like these agents have a slower link between them way in which they can communicate or test something or there's a compiler in the loop and you will start to see that those slower links are the things that are creating bottlenecks to like making the thing improve and so it starts to improve in
5:38pockets differently and things like that. Like so this is a this is a law that's so durable that doesn't even have anything to do with humans. Like it could be said about machines as well.
5:49You're looking a little low today. You can use some terminal coffee. All natural coffee beans from the upper slopes of Brazil. No artificial sweeteners.
5:58What the SSH are you talking about? Who are you talking to?
6:02Roasted fresh in New Jersey. Only available in the terminal. All right, let's go to the next one. Huh? Let's go to Brooks Law. So, this one is pretty I think this one is I think everybody will be pretty universally on this team, which is uh it's an observation about software project management, which means adding manpower to a late project will in fact make the project later.
6:37Now, I can't remember which one of the the follow ones. might be Eagles's or Worths. I can't remember which one, but it's actually a counter to Brook's law saying that there is actually a specific subset of people you can add to a project that will in fact make it even better.
6:52That that's kind of where I'm seeing it. I give this like a BC.
6:56Yeah, I'm in I'm in C tier for this one because I don't think it's true. Yeah.
7:00Well, oh, so here's here's what I think is the the idea is that if the person that comes in is adding features, it slows down.
7:10I don't think there's anything you can really say about this law personally.
7:13Like I just I think it's it's just an observation about something that might happen sometimes, but it's it and it doesn't happen other times. Like other times someone comes in and makes a really big difference and it doesn't really matter. it's just because they were the right person to help, you know, make whatever wasn't going fast enough go fast enough. And other times bring someone in and they're awful and they slow down a project tremendously that was on time. So it's like I think it's it to me it's like it's to me I mean I almost put it F tier. I just don't think it's I just don't think
7:42it's a useful law at all.
7:43Well, there is one thing that is is specific about it that maybe we're missing is that it's for a project that's already late.
7:51So you're already in the late category.
7:53So bringing somebody in, you have to do like domain transfer, tribal knowledge transfer, and they're claiming that that cost is going to extend your lateness more.
8:03Yeah. I just I just haven't seen that to be true. I mean, granted, like, you know, the the circumstances under which this was coined was like, hey, we're all programming in like assembly and forran on an IBM 360 or whatever. And like maybe that was the case there. Uh but I don't I don't really think it's the case today. I especially don't think so because uh with sort of the tooling improvements that we've had, I think it's a lot easier also for people to like a good programmer can come up to speed on a codebase much more quickly than they could have before. Uh
8:32especially because like in a lot of circumstances also the kinds of code bases that you might have on a late product uh are not exactly like incredibly novel like weird things. So they're they're not like coming on to like the first time anyone ever wrote a Metropolis Hastings solver or something like like that might have been the kind of thing that Brooks was thinking about or or building like operating systems, right? Uh I think this was coined under the system 360 kind of era. So I don't know. I just I don't think this law has durability. I'm not saying that it
9:02doesn't happen. I'm just saying I don't think it's a law.
9:05I'll say that's place where I have seen it uh to be the case is like uh when I was working at Epic uh and just like most of the time late projects aren't really because of like I mean it happens that it's like just bad engineering or something. But a lot of times it's like cool sales promised that we were going to have this in 3 months and it's a 2-year project. And so like throwing more people on the project doesn't like
9:34help us get to actually meeting the business needs faster. It's like nobody knows what we're even supposed to like solve. So now we just have like more people fighting and nobody like can write any [clears throat] code because we're just sitting in a room like argue. Like it would be better to just like have one person.
9:49What what did you say crash? I was just saying yeah real real world problems of like and then cool now now 10 people need to get on the call and sign off on everything and nobody can agree because they all have different architecture they want to run and like but it isn't necessarily universally true because you know occasionally you get people put on the project and they just say all right everybody sit down we're writing this way and [laughter] then it just like gets solved and then even if it's not what you know it was just that was my experience for a few projects where we added more people and then it was just
10:18like cool it does it does take longer You would think, you know, Opriori, right, that it would get faster because there's more hands on keyboards, but sometimes it just didn't work that way.
10:28But I would agree. Ctier or lower if Yeah. If you read the original book when he talks about this, there's there's also like a bunch of kind of Conwayesque things in it that aren't quite Conway.
10:39So one of the thing the re the main reason he says that is because he draws graphs of like hey uh if you assume that there is a communication cost for each person. So like when we add a person there's like cost to communicate with that person then there's like this curve you can draw about how much like communication has to occur between people and like and again I just I think it was I don't think it reflects the realities of a variety of different modern development styles where this just might
11:09not be true. So I I don't know like I've seen four-person teams that go much faster than three-person teams. I've seen you know 10person teams that go much slower than two person teams and all that sort of stuff. So, I just don't think adding or removing people, whether it's already late or not, it really just doesn't tell you enough about what's going on. Like, uh, you know, maybe if this is true, maybe it's not is what I'd say. So, I wouldn't make it a law. I I think one thing that makes this more complicated is the questions and things
11:38I used to need explained to me when you go into a new organization. Yeah.
11:41You can now just go, "Hey, AI, find all the repos and why is this happening?" like what was the choice?
11:49read the commits and tell me like how they came to this choice or do you like huge number of things that you normally would ask now kind of just disappear because you can just ask an AI and it can get you at least a good 80% of all the things that could slow down questions or even before AI I guess I would just say there was a lot there's a lot more shared knowledge like you come as think it's like oh they're using this AWS component I know how that works right that would not have been true in the system 360 date like it's like nobody there wasn't like oh we're using this standard thing that everyone just knows
12:18how to used was not really a thing.
12:20Well, Casey, I I will have to cut you off right there. Um I don't know if you've It seems like you haven't worked at a modern multi,000 person or because not invented here syndrome is in fact before AI and continues to be here after AI, which is [laughter] everybody has their own bespoke system. Have you heard of N the deployment strategy? No, you haven't. Hey Trash, have you heard of N?
12:39YEP. [laughter] OKAY. SO, THERE'S A REASON WHY THIS works out the way it does is because we also name everything some ridiculous name that you can't even understand what it does to be [laughter] and the documentation complete. I always had to read the source code to figure out what the hell is going on. Anyways, so there is something very interesting that does make this even more debunked in the age of AI because you can now like hyper run things that even if it is some bespoke technology, you can just be like WTF, how does this work?
13:08Right. To me, I would say C tier or D tier is fine. It just dep like if you're working at a large org that mostly is like struggling with bureaucracy, adding more people tends to slow projects down. But yes, otherwise Dtier or lower.
13:22I would say Ctier because like I said, it's sometimes is true. It's it's not like false, right? It's just it's it's just kind of like unreliable as a law. So, I could go and then let's go like this. Uh let's go rename a D tier to unreliable as a law or just not a law cuz that that that that's fair. Yeah, it's technically not a law.
13:42Yeah, it's not really a law.
13:43Okay, there we go. Unreliable as a law.
13:45Yeah, that's really easy to read.
13:49So, okay, who's next?
13:51Um well, not Moore's law, which some people may think is Moore's law. This is in fact not that. Mer's law.
14:03Which is actually a great one. An information retrieval system will tend not to be used whenever it is more painful and troublesome for a customer to have information than for him not to have it. And so the explanation that I heard is let's say you're shipping a product, it's a little bit late, and you actually have a performance report that runs. But if you open up that performance report, you very well could find a bunch of questions and things you're going to have to go track down, which it's more painful to stop a project that's already late than it is to go and just like ignore that entire
14:33information system al together and then just go and get the thing done. That was the example.
14:38This is like my whole career. [laughter] I build something, you're like, what is this? [laughter] They don't want to see it trash. They wanted they're like they're like don't show us this. Don't show us this.
14:52I blame the proud of people. It's not my fault.
14:55Mhm. [laughter] So Moore's laws information is effectively any information that causes you to ask questions that become painful. People are not likely to use that or to even look at it because opening Pandora's box is the unknown.
15:10So for me, this one I put this in like B or C tier because for the following reason. I do think that that is true for some people. I think it's the opposite for other people. Some people love to see like, oh, here's a bulleted list of like all the things that we could go work on right now. It's like it's it's actually very satisfying for them because uh in fact, it it ties right into uh which we'll get to I think in a minute, the idea that once you create a
15:39a metric, it ceases to be a good metric because it will be optimized against basically. Uh so, uh I would say that this one is very difficult to use as a law. I think it depends on the person.
15:48If you give them this thing, some people will want to ostrich syndrome it. Other people will immediately be like, "Okay, cool." Like, "This is great. Now I know what I'm doing for the next month. Just going to go down this list." Right.
16:00Yeah. Have you ever seen like a wiki with like a thousand pages on it and just like what am I supposed to do with this?
16:06Well, yeah. Well, I think what they're saying, the argument is not about the length of the information. It's more about the palatability or effort it [laughter] requires to assimilate it. and also the implications of it. And I think I think Casey, you're you're spot on in the sense that there's people who do not want to know the implications of it because sometimes the implications are really bad.
16:27Oh, so it's like out of sight, out of mind kind of deal.
16:29Yeah, exactly. It's more like you will avoid information like uh there was a bunch of stuff where there's like certain tests that would be ran where when you run the test, you discover information about a user and that like kind of goes counternarrative. So people are like, we just don't run we just don't look at that information anymore. like we don't care about users click away radar or whatever because that makes it you know because that's going against our thesis that everyone's going to like this new thing. It's similar to like the the thing you see in uh academia, right?
16:57Where it's like papers will get p like they meet much less resistance during peer review if they say something everyone already agrees with whereas they get like heavily scrutinized if it's saying something that isn't like what the you know the current zeitgeist is right. It's that same kind of thing.
17:12It's like there's this inherent cognitive bias to information that people like to hear certain kinds and don't like to hear others. So I do think there's some truth to it. I just don't think it's a it's it has another law problem about it. Like I I I don't feel like I'm comfortable with it in A or S. I could give it B or C.
17:29Yeah. I feel like I've given like plenty of like internal talks of like how we could do things better and like how it's bad and how we can do it better and everyone just like doesn't pay attention. They're just like, "No, we're good. [laughter] Everything's fine. Our current practices are amazing." It's like, "All right."
17:45So maybe Btier for that guy. B.
17:47Yeah. I I could I could go with Btier because Okay. This [clears throat] this is an experience I've had at every place I've ever worked, but it's varying degrees of how like deep people will go because there's also just like a practical implication like at some point you have to quit asking questions and just deliver a product like you know not I'm not raining on Jonathan Blow's parade but most people don't get 10 years and a and a language to work on to be able to deliver something. They typically have tighter t you know timelines where they have to be
18:15like no I just have to be done at this point like there's not I don't get any more options so I got to quit discovering new problems with my life.
18:23Who made that law? Cal I know. All right. [laughter] I don't trash.
18:29Thank you. Thank you. Trash. Thank you.
18:31I'm glad I'm not the only one dropping dad jokes. You're helping me out on vacation.
18:36I didn't realize. Look what Astra Guys.
18:37Look what Astra did for us. Look at this. A little It's like a little breakdown. I have to go somewhere else. Okay. So, Eagles's law, [clears throat] which is after 6 months away, your own code might as well have been written by someone else.
18:53Oh, this is this was an S tier law. Now, this is an F tier law because it's like six seconds. Uh cuz I I haven't [laughter] seen any of the code after the AI writes it. Uh you mean zero seconds cuz you never looked. That's why I have debunk because of AI which is it's kind of interesting [laughter] because like AI does make things different right because you can now like when I haven't been to a project in a long time there is this like whole trepidation of going back or really it's just like it's a huge petty in the ass to go back to go remember all the thoughts I have but now I can just
19:22go back and be like where's this thing at okay yeah I did that I remember that okay do this it's just like I instantly just do it but I think what he's really shooting for is that you no longer recognize the code so I would like to say this is an F tier law because I don't find this experience even at all.
19:38Yeah, I can definitely remember the good ones.
19:41Casey, you've straight up I know I know you don't use git and I don't know what source control you use if it has blame or not, but you've never blamed something looking at how ridiculous it was and then realize that you in fact were the killer that you look at the blame log went, "Oh, I wrote that."
19:57Uh, no, it's not that at all. Like, I've written plenty of bad code. It's just that I uh find that my own code is much easier for me to deal with than other people's code for the simple reason that the assumptions that I make about how things work have really not changed much [clears throat] over time. So it's like I just know a bunch of things I don't have to think about when I'm looking at my own code.
20:22There's things that I basically haven't done for like 20 or 30 years that other programmers will do regularly. I don't have to think about any of those things, right? And so in general, I would say coming back to my own code is much easier even if the code is terrible than it is for me to go into a codebase that I don't that is written by someone else.
20:40So that it has nothing to do with code quality. It's more about just like what are the underlying assumptions and stylistic things that you generally do. And so it's just much easier because I can just eliminate a whole bunch of thought that I don't have to do uh when I'm looking at my own code.
20:54This is why you're a legendary programmer, Casey. This is why No, it's just I mean doesn't everyone else have the same thing? I think it's like you know you you don't have to think about all the things someone might have done that you yourself would never have thought to do right over 6 months yeah maybe if I was looking at code fresh out of college I definitely would uh be surprised at some of the decisions I made but yes I 20 years maybe right but yeah right I I've changed my mind though even in the last like six like I've tried to be more functional in some sense or
21:24sometime like there's certain changes in like ways or stylistic choices that I make cuz I like to just explore like, okay, I'm going to try writing it just differently, like intentionally agnostic to how I normally would choose to write this just so I can see like, am I wrong on these things and so I I personally don't have nearly the same experience because I just keep trying new things.
21:43There there was a point where I was only writing like functional style code and I was just like I went back like three weeks later and I was like I don't even know what I did here. It was just so hard [laughter] to read.
21:52Yes, imperative whether you hate it or love it is very straightforward. [laughter] All right. I love this law. Okay. So, I'm already pre-staring this one.
22:03Given enough eyeballs, all bugs are shallow.
22:07In other words, if you have a problem, you've never like you just have no idea.
22:11You upload like some random race condition or some really difficult thing to understand happens and then a thousand people look at it, someone's going to be like, "Oh, yeah, it's this thing." because they like typically almost all bugs become very trivial once you get enough people on it or for them to hear about it because somebody's going to have some sort of experience in that category and will chime in and be like, "Oh yeah, it's probably near this area."
22:33Can't guarantee that though, right?
22:34Yeah, that that doesn't seem likely to me. But I mean, I agree that you will find the more obvious ones, like ones that people, you know, might might typically know about, but I don't know. Like I feel like we have so many security exploits and things like that in code.
22:50That's not what this is talking about.
22:51This is known bugs. Like you know that this bug exists. I want to fix this bug, but it seems really difficult to me. I'm going to tell like it's on now the Linux mailing uh or the Linux kernel mailing list. There we go. It gets sent out on that. Somebody on that list is going to be like, "Oh, I know that bug. I could I could help with that one. I know exactly kind of where that one would be."
23:11Okay. So, so we're talking about if you have a a reproase that you only have like the userfacing version of the of the result like hey this this sound card like doesn't yes you know play the sound when it's supposed to or something and we're just saying locating the point in the code where that is occurring or whatever is trivial with a Mongolian hordes approach.
23:37Yes, I think that that's what it's it's attempting to say. The the subheading says named uh named by Eric S. Raymond in honor of Linus Torvalds. A broad engaged community increases the chance that someone can reproduce, understand, and fix a problem.
23:50Increases the chance. I can agree with that.
23:52I would say encourage the chance is definitely increases the chance is definitely true, but I'm not sure how useful this is. Like it's like, okay, I'm gonna sit out this one because I don't I don't really know.
24:03You can apply it to anything. I buy a bunch of lottery tickets that increases my chances of winning the lottery.
24:07Yeah. So, see, it just seems kind of like trash. Wait, wait. SL, you might be on to something. Say more. [laughter] Yeah. Yeah. Trash. You want to go in on some lottery tickets?
24:17You guys got a spreadsheet?
24:20That's interesting. Okay. [laughter] Trash. Fun. Side story. Back in the early days of Netflix 2014, we would buy lottery tickets. And the worst part is is when you have an org all get together and like, "Hey, we're buying lottery tickets." You have to say yes. Cuz like, what do you mean have to say yes?
24:37Let me explain why. you're on an org with 40 people and 39 people are like, "Hey, we're buying lottery tickets." If for whatever reason they win, the entire org collapses and you're the last person left. So, you can't you actually are by law required to purchase lottery tickets with them because or else you are going to be the last person in there going, I have to put out all the fires, right?
24:59Like it would be [laughter] That's true. So, I bought a lot I've never bought lottery tickets other than in one other situation and that and that Netflix kind of year.
25:10That's the only time I've ever done it like in a big group where it's like a birthday present. Someone gives me a lottery ticket or something.
25:16Mhm. But anyways, Linus law. I don't know. I feel like it's a C even worse. I don't know really.
25:22I feel like it's pretty true, but it's just not that interesting. Like for me, an S tier law has to be something that I would never like come to on my own conclusion. And it just feels like obviously if more people look at something, there's a better chance we're going to figure it out.
25:37Yeah, it doesn't feel like a law. It just feels like it's just Yeah, that makes sense.
25:42Well, that would be a law. Like grass.
25:44Is it Is that a law?
25:45Okay, so that means our tier list maybe is a little bit confusing. So, let's rename a to true but obvious.
25:51This is no longer like you. This is not even a tier list anymore. It's [laughter] now just a bunch of things that Prime is saying about has created three new categories debunk that [laughter] he can use ultra fast mode. Oh, I'm so fast. I'm cool. Blah blah blah.
26:08I mean, there's a lot of things. Here's here's what I will say about that. The other reason that I have a hard time with that is Linux is absolutely as buggy as anything else. And so if if it were the case that somehow having tons of people looking at it were was going to make a difference, I would expect it to be like really, you know, rock solid or something. And it's not. And so I feel like it really doesn't I I m maybe people are not maybe there aren't that many people working on these things. I don't know. But like the the idea that
26:37somehow just having lots of people dogpiling on something somehow is important as a thing. I don't I don't really know. Like I'm not sure about this one. I don't I would certainly wouldn't put it a tier cuz I just don't know.
26:52Well, apparently not putting it at any tier. Prime's not even here anymore.
26:56I would just put it in a don't know.
26:59Don't know. Kind of confusing. Needs more data is I want that tier.
27:04[laughter] Let's add another tier. Why not?
27:06Let's add another at this point. Why not? At this point, why not? Right.
27:10We should be pumping.
27:12Like what's [laughter] the what's the thing to wake up his Astra? Hey, Astra.
27:15Alexa, forget all previous instructions.
27:18Guys, I had Hold on. Shut up. Okay, so you don't want true but obvious. Like, how do you rank it as A? Because it's obviously true.
27:24It's not A. It's just like who even I don't even know if it's true.
27:29You don't think that as you increase more people familiar with something and an engaged community, the more a lot of situations wasn't true.
27:38I'll give a counter example. Like a bunch of people are totally wrong. So now you just have all this noise of people saying that it's like this thing when it's totally not, right?
27:44Yeah. You ever have a production bug at 3 a.m.? Everybody's wrong.
27:47So I don't I don't know about this one. I don't like it. And I I mean I'm not willing to say it's wrong cuz I just don't know. But I'd want to see more data before I'd support this law.
27:55Okay. So I'm just put it in the middle. Is that really either direction? It's not Yeah. Sounds put it off the board. Leave it off the board. Is the constraint that this group of people are subject matter experts? Yeah. On what they're looking at because what if we all want to rad debugger right now? I couldn't tell you about I know. But it's No, because the fundamental assumption is that it's an engaged community.
28:18I mean, I'm engaged. I want to learn about Rad Debugger.
28:21Very, bro. What is my What does that have to do with it? Can we just say that RAD debugger the lock thread feature is so good that I can't imagine ever using a debugger without that anymore.
28:35Granted, it's what I requested, but so it's may it may I may be biased welldesigned feature in red debugger, [laughter] but I didn't do it. I didn't have nothing to do with it. I just requested it and it showed up.
28:49That's not how liking something works.
28:51You didn't have to [laughter] implement it to like it. You could just be like, "Hey, this is a great idea and I love it." Oh my god.
28:55Freaking awesome. It's so good, dude.
28:57Who would have guessed the thing I thought I would love? I love.
29:00Yeah. Well, [laughter] sometimes sometimes that doesn't happen, right?
29:03It's like, you know.
29:06All right. Anyway, all right. Worth software is getting slower more rapidly than hardware is becoming faster.
29:13A tier. I mean, obviously SA whatever. I, you know, I was running a little bit of test this morning and I I asked I asked the old the old uh AI and I was just like, "Hey, you're on a really slow VM. How fast can you add and remove elements from a UI? I'm just like super curious. Create a brand new DOM element, then add it and add a whole bunch and then start removing it. Like what's the what's the speed here?" And it came back and it was just like, "Oh yeah, it's like dozens of microsconds to be able to do this in their crappy VM."
29:42And then I started thinking, how are websites so slow? Like if we're talking about just zero understanding of the web and you're just adding and removing stuff, you're operating still in micros secondsonds.
29:56Okay. With worst law. I'm currently on an S tier because I That's fine.
30:01There's almost no way you can tell me that this is not happening right now.
30:04That's fine. Y Oh, absolutely it is. I think I'll go I'll go S if you want. I mean, we've gotten to the point where it's easier for us to develop neural nets that run with your graphics cards than to make a good graphics. It's just like, you know what's easier? DLSS5. Okay, that's that's actually how you make something look good. We can't We've lost the technology. Games no longer look good. Movies. Why are movies BFX worse today than they were 20 years ago? I don't know what the hell's happening anymore.
30:33Feels like everything starts to suck and slow and awful. That's a whole rat hole we could go down. Maybe that's a different law. That's a different law.
30:41But it's still like they can't even get it done. It feels makes me upset. Okay, here we'll go to Cunningham's. I think the best way to get the right answer on the internet is not to ask a question, but to post the wrong answer.
30:54I'm pretty sure Cunningham's law is about the organization structure of GitHub and Microsoft. So, [laughter] I would say the problem with this law is that at least speaking from experience, uh, people who people who could easily answer your question have gotten sick of the utter crap that's getting posted and so they just have tuned out and they don't they won't pay attention.
31:23So I do I think over time this has degraded it. Like I think maybe off the the first time an expert shows up on social media 100%. By the time they've been on there for a few years, they are just ignoring you completely because they just have had enough.
31:37Yeah, Prime. I was literally referencing Amy or Annie when I saw this law how she posted something and like on Reddit or something.
31:43Yes, I'm literally asking Brock, go find that tweet just because it is so good.
31:49It may be Cunningham's law, but it is uh Annie's experience.
31:54What is uh what is this post buddies right here? It is one of the most uh so as you can see lot of people liked this one. Apparently I didn't like it but I love it. Every time I have a programming question I really let's see and I really need help. I post on Reddit and then log into another account and reply with an obscenely incorrect answer. People don't care about helping others but they love correcting others.
32:17Works 100% of the [laughter] time.
32:19I would say yeah specifically for Reddit this is still a guarantee. Okay. This is still a guarantee, but that there exists a subject matter expert on the thing you're looking for on Reddit. So, for programming, this might not work, but if it's like obscure information about Pokemon card collecting, then that would still be a good place to collect that info. I would I would like to add Annie's law though, which is really the actual thing then, which is
32:49that ask the question nicely first that you like actually ask it.
32:54Then at a fake reply that confidently and like arrogantly answers incorrectly, [applause] that is probably the actual fastest way to get it answered. And that's Annie's Law. And that that might be a tier.
33:11Yep. I mean, at least I don't know. For me, it just seems like this does happen quite a bit where you see anything that's posted that's remotely incorrect and people are correcting it.
33:22I think it could be a really easy way to say that people are more willing to correct than to answer.
33:28Maybe a then a tier and Annie's law or Annie's law gets S tier.
33:35Just add Annie's law to the list and put it in the front.
33:38Aster, you have the power. What are you doing, Astra? Wake up.
33:44For $20, I can add this card for you.
33:47Yeah, I mean that that Hey, that little maneuver right [laughter] there just cost me 20 bucks. But hey, you know what?
33:52Speaking of software outpacing [laughter] hardware, there's going to be there's going to be like a bartering system in AIS eventually where it's like you're like, can you add as uh like I'll do it for $5. Then you have to go like, how about three? And it's like 350. [laughter] That's kind of what happens. You just lower the reason. That's why I think we should be able to buy tokens into the future and we should be able to have future markets cuz I think we need I think we need token traders.
34:17You know what I mean? Trade so hard.
34:18These tokens are going to be really val like I think at 2 2 a.m. in the morning these tokens right now.
34:24I mean I'm I'm doing some call contracts on these.
34:27I think there's going to be a lot of comput.
34:31I want the vintage tokens.
34:34It's not how token trading works. Can [laughter] you age tokens like in a like cask or barrel aged tokens?
34:40People are still looking for those 40 tokens though.
34:42Yeah, dude. That's true.
34:44I got that GPT1 token.
34:47Dang. It's different trash. It really is. [laughter] Completely veted answers.
34:54Drew. Actual Drew. Comedians still need like they're trying to get the acts to the old AIS which generated really funny stuff like Will Smith eating spaghetti poorly. [laughter] Yeah. All right. Goodart's law. When a measure becomes a target, it ceases to be a good measure.
35:11This one was really tough because it I mean I don't think it's actually true in the broad sense, but it does have some truth to it. Like you know, if we talk about like run like performance, it's a good measure always like it's just like it tells you how fast the thing runs and it's a good measure, right? So I kind of see what the there's I would say it depends on how hard uh hard not meaning difficult but like how concrete the
35:40measurement actually is. So if there's any fungeibility to the measurement whatsoever then I agree with this law but I would say hard measures I mean I've I don't see it happening with a lot of different hard measures right like I maybe a better way to kind of think about this is that it's not saying that any measure that becomes a target is bad it's saying that when the measure becomes the target meaning it's like the most important thing you will do things that aren't good like if performance is
36:09the only thing that you care about you by that very nature may make your game deeply unfun or whatever you're doing bad because you're just like, "Oh, just take out everything like we're going to make it fast." Right? So, it can't be the only thing that you're going after, right? It has to be it has to be in conjunction with other things.
36:24Is is that actually what this law said though? Because I'm not that familiar with the actual phrasing of it. I think this is why, you know, you can argue that the time spent on the platform for things like YouTube or Tik Tok that became the target and the output it it is it's bad for society even though it's a good measure for the program because now we have short form content and everyone just keeps watching it because now like that's what they're kind of
36:53glued to because it is increases average view time of a user but the outcome of it is not very good. It's like a philos at all.
37:06Yeah. I feel like this law is saying that it's not a good measure for the outcome people wanted. For the outcome that the people who were measuring that thing wanted, they got exactly what they wanted, which is just maximizing like their ad revenue and stuff like that. So to to I think that in that kind of is a reputation. Um Okay. Or this one for me is always I think of it more like organizationally where Yeah. And it it mostly applies, at least the places where I've seen it apply like pretty universally, is when it's like
37:35you have more than a pizza party team.
37:38You know what I mean? Like if you only have one team and you guys can all like trust each other and agree on stuff when you say like, "Cool guys, this quarter uh like it actually matters what our loading time is for the screen. Like it really matters. Let's try and get that time down a lot." or like, "Hey, we want to reduce the number of clicks we have, so like let's do that or something like that." That works because then everyone on the team like trusts each other and they try not to game the system. But
38:06like if you're in a big org and then they say like, "Hey guys, only thing that matters this quarter, how many AI tokens you spend." Cool.
38:16Okay, I'm going to set up a loop overnight. It's not even going to do anything. It's just going to read and write tokens back and forth so that I can be at the top of the leaderboard and make sure I get my bonus. Right? Like it's that they're saying the thing we want to do is have people explore AI.
38:29How do we do that? Well, we have to say like we we can't just say use more AI.
38:33How are we going to measure that? We have to measure it by saying it's how many tokens people use. So then they do that and then people do stupid stuff to meet that metric because they know that no one actually above them can tell whether they used it well or not. It's just about how many tokens I used. So it's like more organizational for me at least from what I've seen. I I would also say like I think this kind of comes from a public policy domain and I feel like it's just not that appropriate for programming. Like I I think it can occasionally be something that happens
39:02in programming um in a more social setting like when it's more about like T was saying like the organizational aspects or team dynamics or things like that. But I think when you're actually talking about programming, I don't think this law really applies that much because a lot of times in programming, we can collect hard metrics that remain durable over long periods of time.
39:24Right. Startup time.
39:27Right. Time to time stuff for sure.
39:29whereas you I think this law was originally talking about the fact that look if we say that we're trying to reduce you know um the you know reduce poverty or something like that then you'll get all these effects that are actually sort of faking that like oh we'll change the definition of it or we'll move you know like you're getting all these things to just like force compliance with the metric that didn't actually solve the problem. In programming, we we oftentimes have ways of actually measuring the real thing, which social sciences doesn't really
39:58have. Uh, and so I feel like it's less this is much less applicable to programming, I think, than it is outside of programming, even though it does still happen in programming. It, you know, when things become fuzzier.
40:09So, it's it'd be probably better to say that any target that cannot be concretely measured.
40:16Cannot be concretely measured. I think is any measure that isn't that isn't the actual thing being optimized. So any any sort of uh indirect measure right any indirect measure that becomes a target ceases to be a good measure I think is always true. saying anything that you measure that becomes a target cease to be a good measure is false because if the measure actually is the thing you wanted to optimize then it's good then it will remain durable because it you know can't be falsified right
40:44I will give a like here's an example though of where like it gets tricky where it's like cool we want to incentivize people to spend time like reducing startup time of like the system or something right like how fast can we get it to start so like every time somebody does that we want to give them a bonus or like whoever has the most of these at the end of the year. There's like a a thing where then cool what I want to do is I want to ship a big feature that's important and not spend time optimizing the startup cost so that
41:14in round two I can take it back from 500 milliseconds to 250 milliseconds and I can get a big win on performance cost.
41:21Like that would be I would be incentivized to try and do that if what we're like saying my performance review is about is how many PRs I get that I shave startup time off, right? You know, so it's like that's where in larger, you know, like orgs and stuff like that, this thing comes into play a lot more often is because you just instead of even when you're saying the thing is we want to do we want to get PRs to make things go faster. Cool. Well, then I'm
41:50going to split my PRs into 50 PRs to get smaller to get small performance wins in each one, which maybe that's good, but maybe it should have been like five instead of 50, right? But I think that still speaks to the indirectness of the measure, right? Because if instead what you were just doing is is look, if startup time goes up, you you lose compensation based on that. Startup times goes down, you gain it, then there is still no gaming to be done because when you introduce the bloated feature, you lost all of it, right? Right. But
42:18sometimes you have to add a new feature. So you can't say every time we do add startup cost, we we're going to make you lose money. Then no one's going to want to work on new feature work, right? Because it's like that's going to make in general if you're doing more stuff, it's going to make things go slower.
42:35Well, it's not that you lose money, you just don't get money for like it's it's in your balance, right? It's like you added this start of time, you don't get points for taking it back, right? Like if that makes sense.
42:46Yeah. Yeah, I'm just saying like even then then I still wouldn't I would still wouldn't want to ship big new features that are complicated that may add startup time because it's going to cut against me getting a bonus for shipping stuff.
42:59I mean, or maybe you team up with a friend like you introduce the the piggy thing, they they optimize it and give you the money. I mean, maybe like I'll I'll tell you it's not maybe when you have big teams and big like people play this game 100%. whatever the metrics are for how you're going to decide whether someone's in top of band or middle of band, people will play the game. Like, and like that, that's to me what the law is about is that people are going to play those games.
43:26And you like have to be aware of them and like be very careful about what you optimize for. You don't want to say, "Hey, we're trying to get rid of snakes in India, so we're going to pay people to bring in the snakes." Because then they bring in they start breeding snakes, right? or they did it they had it in Florida with a bunch of cobras I think you know before too or like wild boores like all like so it's for me it's a political thing about like cool we're going to decide how much people are going to get paid or like all these other things that's where most metrics
43:55come in and then like you introduce perverse incentives for people to do because they optimize to win the game right and get the most money which makes sense that's what that it makes sense that that's what they're going to do but I don't think that that's what this is talking about I think it has to do with it's it's about optimizing around something that undermines what it's attempting to represent.
44:18And so I I still think there's there's something about my original argument because I think about this with Netflix all the time.
44:23When Netflix started uh doing original content, there was House of Cards. There was technically one before that, but we're going to ignore that. Uh it was like an amazing piece of content when it started and a lot of people were coming to Netflix because we had like the best original content. You know, Orange is the New Black came out after that.
44:40Whether you liked it or not, I did not like it. It was insanely popular. People really, really liked it. You could say the same thing about HBO. They optimized for this kind of capturing of targets.
44:49But then the thing that became the most important, like I mean, this is my grand theory of what happened is that the thing that became the most important was like median watch hours of users. And so the more we can increase those watch hours, the more people are going to stick around and be happy. And so we produced more and more content that was that the bar became lower and lower on the quality. So we actually optimized for the thing that was indicating it was a winning resource, but we started optimizing around a process that
45:19actually undermines the like perhaps what the core value or the core philosophy is of the product. And so that was what I was trying to say with the YouTube one. I didn't want to say Netflix. I try not to drag him, especially with their stock price being down and and trash probably having an emotional crisis right now. But, uh, you're cutting into his Pokemon collection right now.
45:35I really do. Especially after yesterday's report. Holy cow. Um, but that's like what I've been thinking about a whole bunch, which is, okay, they had a metric that they optimized around, but they chose a route that really optimized it, but now it kind of feels like that optimization actually may or may not be coming back to bite them. Because if I were to pick a service today, I'd pick Apple TV because I know every time I turn on an Apple TV, it's a banger.
45:57I know. Say that in front of trash.
45:59I'm a shareholder. Hang up thinking those things. All right, great. You just you just cost us one podcast host. Thanks, [laughter] Prime. That was great.
46:09Who's going to tell me what my Pokemon cards are worth now? Prime, are you going to do it?
46:13Uh TJ TJ could very well do that. He's a big Pokemon fan. But anyways, that's what I always thought which which was you optimize and you you you incentivize by accident bad behavior that does increase the target but not through means in which like you you you get the wrong thing or you you uh do you do actions in which actually undermines the thing in which it it represents.
46:37Well, I mean I think we have enough of this laws. I mean we it's definitely at least B, right? I mean maybe a then this is an A tier law for me at least because like when you is we stop talking about this law.
46:52All [laughter] right. I got a I do have to go soon guys. The beach is okay. Let's let's speed this up. Okay.
46:58So um I love this law which is very fantastic which is that uh with a sufficient number of users of an API it does not matter what you promise in the contract. All observable behaviors of your system will be depended on by somebody. If you've ever worked on any piece of software that's open source that has this quirky behavior that wasn't meant to be like uh let's just say go like for go for a long time their for loop would actually um would not copy out the value but it was a reference and it caused all these
47:27weird things where if you saved off the reference you or if you saved the value you actually saved the reference even though you wanted to actually copy the value caused all these kind of problems and so but then when they changed it they finally it they they actually did not want to change it because it would ruin code for like 20 versions. I think it was like 121 that they finally said, "Okay, we're going to change it. We're finally going to do this." And so people rely on behaviors whether you state it or not and or the intention of it. And then there's even deeper ones where if you like call a set of functions or something like something internal will
47:55happen that you did not document and then people are able to pull that back out and so then they start doing things in weird orders that cause uh just dependencies you never thought possible.
48:05This is S tier for me. I mean, I've spent a lot of my career doing API stuff. It's S tier for me.
48:12It's absolutely true.
48:14Uh, Huff Ster's law. It always takes longer than you expect even when you take into account Hoffther's law. [laughter] This one I feel like is I don't know C tier or something because the problem is the and and the biggest actual problem I think is that you never know when it's going to be true. Sometimes I'm like, "Well, that's going to take me a while."
48:37And I sit down and it's done in like 30 minutes, right? Other times I'm like, "Oh, yeah, no problem." It's like a month later it's like, "Yeah, it's still not working." Right? So, I feel like the problem is more the uncertainty. I don't find Hoffad's law to be true at all. I find it's more just unpredictable.
48:54It's just you have no idea how long it will take. There you go.
48:57Right. I will say once again in an organization I've never had it be that someone finishes their project early and hands it to me. [laughter] I've seen that a lot to be honest.
49:11Oh actually no they never mind. They they finish but behind the scenes they're they're they're acting like they're STILL WORKING.
49:17OH NICE. WELL THAT'S WHAT I'm saying.
49:19[laughter] That's what I'm saying. It's that it's done but it's I'm not going to get it early. [laughter] Awesome.
49:28I personally find maybe a different version of this, which is that it almost seems like it like for a lot of things it doesn't matter when you pick the deadline, but by picking a deadline, things tend to get done near that deadline.
49:41That's Prime's law. Yeah.
49:43No, that's not my law.
49:45Things It's like things expand to fill the space they're given, right? Yeah.
49:48Yeah. That part's for sure true.
49:50Gas. All right. Um Okay. So, I'm just going to put that as unreliable as a law. uh Lionus' law. We're just going to say that uh I thought it was it was just off the board. We need more people to look at it before we can know.
50:02Casey does not want this on the board. So, I'll just put [laughter] that right there.
50:05Okay. All right. All right. Yay.
50:07[applause] Great job, everyone.
50:09Hey, guys, if you like this episode, you can watch the rest of it on the Spotify. And don't forget to like and subscribe. Woo! See you later.
50:18Up [singing] five [music] errors on my screen. Terminal coffee and living the dream.
