Crafting Code Podcast

[00:00:00] Allan Stewart: Welcome to episode 12 of the Crafting Code podcast, where we discuss the importance of doing the right thing at the right time with the right tools. I'm Allan Stewart, a software architect, and lately I've been thinking whether consulting means knowingly stepping into severe dysfunction.

[00:00:16] Dave Adsit: I'm Dave Adsit, CTO, and this week I've been thinking a lot about go-to-market strategies, pricing models, and product-led growth.

[00:00:25] Matt Baker: My name is Matt Baker, software architect. Lately I've been thinking about machine learning.

[00:00:30] Allan Stewart: Our topic today is learning from our mistakes. I think it's important for us to recognize that we're all going to make mistakes. It's inevitable, and in some ways that's the only way that we can learn. And so today we're going to share some of the things that we've learned, some of the things that we used to do, and now we realize that there is a better way, or at least a better way for us, times that we've failed and other things like that. So Matt, you want to kick us off? Ooh, okay, yes.

[00:00:58] Matt Baker: Yes. When I think about times that I've failed, I'll start with a particular occurrence. One time I was working on a production system, and I logged into the production database to do some work while the system was under heavy load. It was a system that, due to any number of reasons, it became under scheduled peak load, where they would schedule events and they would happen, and lots of people would be using the system. And during that time, I dropped the production database. I wrote a SQL query, dropped statement, logged into the production database from my computer, didn't wrap it in a transaction, forgot to add a where clause to filter what I actually wanted to delete, and dropped the whole thing. And at the time when it happened, I thought, idiot, why didn't you put a where clause or a transaction around that statement? And now when I tell that story today, I think there are so many times along the way where I should have stopped and said, this is a bad idea. You know, like starting with logging into a production system with the intent to, you know, by hand, go and model it a little bit, especially while it's under load, you know, you never ship on a Friday afternoon. And it's some version of that.

[00:02:14] Allan Stewart: That makes me think about the importance of setting up your system to help avoid those kinds of problems. One of the things that is commonly done is that you don't give developers access to the production database. But, you know, that also has its downsides. Are there other ways that you can set up your system to make it so that it's easy for people to do the things that they want to do? Like, you know, maybe SQL tools should be a little bit smarter. If you run this, it's going to drop the whole database. Are you sure that's what you actually meant? Or maybe the syntax should be changed. To drop the whole database, you have to say something really explicit, like drop entire table or something like that.

[00:02:54] Matt Baker: Yeah, I would love that. It would have been nice. In the moment, what I champion most now is a pipeline for these kinds of changes. You know, where something where you can write it local, ship it. And I think it's a nice to have if you can run it in a like sandbox environment first, you know, before you then ship it up. But I found that like the act of writing this thing and considering it like a one off job and putting that through a CICD pipeline helps me for one reason or another. I haven't dropped the table using that.

[00:03:27] Dave Adsit: At least not accidentally.

[00:03:29] Matt Baker: That's right.

[00:03:31] Dave Adsit: So along those lines, I once upon a time worked in an environment where we didn't have staging servers or staging environments to test our code. And in fact, instead of just deploying code directly to the servers, probably about a third of the changes that we made, we would just remote desktop to the production. And so we would just go to the production server that we thought was the best one, the one that we typically worked on, and then, you know, make changes there. It's a type of testing and production, but it's not so much the one I would recommend for most users. We were working on a system, a web based system that used effectively a server side scripting language. And you could just log into the box and you could change the files on disk and then you could observe the outcome or the results. Of whatever that change was. And when you were happy with your change, you could copy that file and paste it on all of the other web servers in the cluster. But, you know, we had about a half dozen servers in the cluster. So if somebody got an error with the change that you were making, it could just reload and chances are they would get a different server the next time. And it would work. I'm sure that you can see several downsides to this. For example. Yeah. You never knew if any of the servers were in sync with any of the other servers because everybody was always making changes on whichever one they happened to like. I think, you know, I would sign into Web 05 or Web 06 most of the time because there was a big customer that used Web 04 and I didn't want to mess up their experience. Because some of our customers would log in through the load balancer and some of our customers would log into specific machines to avoid the kind of problem created by the type of manipulations that I'm discussing. You know, one time we had a developer who was trying to figure out why one of the web servers was behaving differently than the others. And so he threw a little effectively like a hidden field or an HTML comment on the page that echoed out the connection string to the database in plain text. And it sat there for probably eight hours while he was trying to debug this problem all day long.

[00:05:54] Matt Baker: This is fine.

[00:05:55] Dave Adsit: This is fine. I'm just dying over here. You know, it's, it's interesting because that's the kind of thing that you end up doing when you don't know what else to do. And when you've set up an environment where it seems like it's okay to work in production and do whatever thing.

[00:06:15] Allan Stewart: And sometimes it's really difficult to know when the work that you're doing is going to have an impact, especially as systems get bigger. They start exhibiting, you know, so-called emergent properties. Things are working differently than you expected them to. And so a production failure that I was involved in that I remember my team wanted to use a shared Redis instance and store some data. And we wanted to use a newer library for accessing Redis. We hadn't used it before. And we thought we had tested it all out and that everything was fine, but we didn't set it up as a singleton the way that we should have. And so it created a whole bunch of connections. And of course, this is the kind of thing that you only see under load. And so we tried it in our staging environment. Everything seems good. Everything is working fine. We did deploy it to production. And then we get operations team asking us why is Redis broken? Because it turns out we had used up all the available connections. And so other parts of the system that needed to use Redis couldn't. And so they went down. Yeah. Luckily, we had a good rollback plan. And so we were able to kind of get things situated, rolled it back, undid our thing, figured out what the problem was and try again. But it wasn't before we took a probably a 10 to 15 minute outage in production because we hadn't realized hadn't realized how greatly this seemingly small change was going to impact things. And now, you know.

[00:07:51] Dave Adsit: So now, you know, actually makes me. I think that this may be apocryphal, but I have heard that at one point after the book Thinking Fast and Slow came out and like all of the info about biases and the flaws in our thinking that humans tend to fall for was starting to become popular. One of the authors of the book was being interviewed and the person asked him, so, you know, how does it feel now that you've identified all these biases you're no longer susceptible to them? He was like, hold on. I still have the same mental hardware as the rest of humanity. Knowing about the bias does not actually overcome it. It just gives you a chance at identifying it, noticing it, and then maybe overcoming it. I think that as we talk through these things that we've done, these mistakes that we've made, these flaws in our logic and reasoning and computing strategies and techniques. It's important to remember that we're going to keep making some of these mistakes unless we intentionally put in place things to overcome them. It's really hard to learn from the mistakes of others, even when you think in retrospect that should have been so obvious not to do that.

[00:09:11] Allan Stewart: One of the mistakes that I've thought about that I've made is actually related to that. I wanted to prevent certain types of problems in our system. And so. I turned to a bunch of static code analysis tools, things like the Sonar Cube. Although that was back in the day where it was just called Sonar, I think. Style Cop. And some of these other things to enforce coding conventions. Some of them can be pretty important. Some of these static code analysis tools can give you important information on if you're doing something that could be very harmful. Right? So like in C, are you leaving the door open for a buffer overrun? Right. And then, you know, there's, there's similar things in various other languages. They're not without value, but in an attempt to prevent problems at one of the places I was working, I got very gung ho about setting up these barriers. If you try to commit code, we've got a, like, I think we were using subversion. It was before Git. And so there was like a pre commit hook or something like that. And so you want to commit your code. We're first going to run this check and make sure. Everything's okay. And Paul, I really ended up doing was just pissing off my coworkers with these rules and, and, and things because I wasn't, I tried to collaborate with them, but I was missing the forest for the trees. I thought that this was a really great idea. It was going to be really important. It's going to make our code quality all the better, but it really didn't change the behaviors other than now, whenever they did those things, they were. Complaining to me that this system was rigid and stupid rather than us, like actually improving the quality of our code.

[00:11:01] Dave Adsit: See, I have, I have the same experience from the opposite direction. I worked on a team where from day one, we had a couple of tools like style cop enabled. And at one point in retrospective, we decided we would run a two week experiment where we turned it off just to see how that impacted our code quality and our ability. Yeah. To deliver code over the next two week period. At the end of the two weeks, we decided that it really was helping us in some ways because the consistency had gone down, et cetera. And so our tech lead tried to turn the tool back on. And after about half a day of trying to correct the problems that it identified over the two week period, he said, we can never turn this tool back on ever again. And removed it from our CI pipeline.

[00:11:55] Matt Baker: Yeah, I think I, so I've been the subject to these rules myself, and then I've also been the person making the rule. Uh, looking back on those situations, I, one thing I wish I could just go back and whisper to myself back then was, would be something along the lines of, are you chasing the right problem? I get why these tools exist. I see that I do believe they have some intrinsic value. I also think it's overblown. I think it's a little bit, and I get why people reach for them because it's, uh, you know, a way to exert some control over a code base, especially as one starts to really grow, maybe even very quickly. And, but, you know, looking back, I, I don't know, I don't know what, like the, the right answer or the second part of this statement saying like, don't use code analysis use, like, I don't know what to say there. And I don't know how to offer up alternatives, but I do know that this stuff gets excessive. And like, there's a limit to how much. Maybe conformity you need in your code. At least there's a limit to how much of the thing you get when you use these tools, there's a limit to how valuable it is. Um, and obviously like there's exceptions and I think these are especially a powerful and security area. Like if you're about to ship out like a, maybe a cross site vulnerability or maybe a, you know, um, like in a SQL injection vulnerability, then you'd want a tool to catch that. And you'd be happy that that happened. But when it comes down to like, we put curlies. This way, you know, or we put the parentheses after an if statement keyword this way. I don't know. I don't know how much value you get, uh, in contrast to the pain and just kind of Allan, you said rigidity. I thought that was a good word. Rigidity you introduced into your system.

[00:13:39] Allan Stewart: For me, when I look back at it, this was a mistake. This was a failure of mine, but the failure wasn't in applying one of these tools or not applying the tool. You know, it's just a tool. The tool. The failure on my part was that I was trying to coerce my fellow coworkers. I was trying to make them behave in certain ways. And it was in a very like passive aggressive way. Yeah. They were involved with the creating of, of the rules and determining them, but they had really no interest in having that discussion. And so I put in place this barrier onto them and they didn't find it helpful. They weren't enthused about it. They weren't in agreement with. Okay. The fact that it was there. And so now these days I try to do a lot of those coding conventions in tandem with practices like mob programming or, or at least pair programming where you can get people sitting down together. It's like, Hey, let's write code together and let's experiment with how we write the code and come up with a shared way of doing it rather than everybody voting. Oh, well, I like the K and R bracket style. And if your braces aren't that way, then you're. The worst and get out and you have to have this many spaces or tabs. It's just, it's a lot easier to sit down with somebody. It's like we're writing code together and let's figure out how we want to make it rather than trying to railroad people into this way that they just don't want to work.

[00:15:06] Dave Adsit: Well, I think there's something really important there that you, what you're talking about, Allan, there is a context in which some of these tools were created and a purpose for which they were created. If you're not operating in that context and with that purpose, then it might be the. Wrong tool to solve the problem. You have the ones that I've used in the past have been built by Microsoft for the, all of their public facing APIs and libraries, et cetera. And so there is very high value and having consistency across those things because it reduces the total cognitive load of many developers as they adopt new tooling and improve their coding practices. If your context is I have five people on this team. And we can't read each other's code. That's a different context that warrants a very different set of tools. Most of them are probably verbal. Like I think about, uh, you know, one of the, one of the podcasts that I like to listen to is words and numbers and they talk, they've got a book out called cooperation and coercion. There's always a way to do something coercively or cooperatively. Sometimes we reach for coercion. As a shortcut because cooperating is hard. You know, you have to have conversations and you have to understand people's concerns. And sometimes you just have to have somebody make a decision for the group. So I like what you said about using mob programming as a way to align coding styles versus a tool that enforces coding styles. On the other hand, if you're a go programmer. The language itself enforces a coding. Style. And everybody is happy about it because they couldn't have an art. There was no argument to be had. The decision was made. You either code and go the go away or you go away.

[00:17:06] Matt Baker: See what you did there. That was nice. And I let go.

[00:17:11] Allan Stewart: And maybe sometimes they're just problems that you should just ignore. You say, Nope, not going to even start in on that.

[00:17:18] Dave Adsit: Does solving this problem. Move us. Being closer to our actual goals. Or is it just a big waste of time?

[00:17:26] Matt Baker: That's right. I have a slightly maybe more abstract one, but I think it dovetails here. A thing that I've done throughout my career so many times. Um, and I probably still do it. This is such a hard thing for me not to do, but, uh, come up with a solution in my head and then go find the problem to fit. I'm trying to think of a good example of this. There's a. Um, that was a big, big buildup to not even have a good solid example. Give me just, well, I've got one for you. Okay.

[00:17:56] Dave Adsit: Dave, you go event driven service boss. Like if you start out with a service bosses, the core architectural component, and you're just like, I'm going to do event driven microservices. Well, what's the problem you're solving? I don't know yet, but I know the solution is event driven microservices. Like, are you. Sure. It's the right solution. It must be because it's the coolest thing I've read about this year.

[00:18:26] Matt Baker: Yes. Agreed. And you've jogged mine. Mine's the decorator pattern. I did this with lots of patterns. Decorator was one of the ones that I really liked for some reason. And, and right there is the problem. Like I had this pattern that I really liked. And so I started looking around like, Hmm, how can I use this? And honestly, I don't know if it was for like self gratification, like, Oh man, look how smart. I am. Or like to try and impress others, you know, similar thought. I don't know, but I do know it was the wrong idea. It was the wrong idea. Then if I do it again, it's going to be the wrong idea then. And it also, as I've gone on, on my career, I started to notice this too. When I build features into applications, like if, if I'm working on an application where I have some leeway to, um, put a new feature into it, like I'll want to be building this feature and talk, I'll start talking about how cool it is and how maybe how flexible it is and how many things we can go do with it. Like never once. I go verify whether or not we actually need it. So like a very, I don't know. I hope that like, uh, I might be blurring this point a little bit here, but I hope that sticks that like, even with like non-coding stuff, I can get my mind wrapped around an axle. Like I've got this great idea, this thing, we need it. And I'll start to just neglect the proof of I've gone out and tested this idea and we need it because you know, often like what you, we all know this, you know, what you think, and then what you learn after testing it out a little bit there. There. It could be very different things. And you get into this spot where you're like looking at your users and you almost start to like resent them because you're like, are you stupid? Like, can't you see the way you should use this? And all the while, like they're showing you over and over again, you've designed the wrong thing. And, uh, you know, I just, I get stuck on these solutions and I know I'm going to do this again in my career in numerous ways. I've, I've gotten pretty good at spotting it in code. And you know, like if you work with me now, I'll talk a lot about, uh, don't build a platform ship. A feature and then build a platform like some time far later, you know, after you've proven out the number of features. But you know, it's going to come up for me in other ways. So anyway, in summary, uh, I am prone to having a solution that I'm really excited about and trying to find a problem that fits and it's just backwards. It just doesn't work. And like the longer you cleave to it, the more painful it gets.

[00:20:40] Dave Adsit: Yeah. There's that kids movie with Robin Williams, uh, robots find a problem, solve a problem, find a solution. that this one, starting with the solution first, it's so amazingly common that we just fail to notice it more often than not. I think it's got some close siblings, like not invented here. You've got to go write your own implementation of the raft protocol for some reason, or heaven forbid, you're like, you know what? Security is so important to us. We are going to write our own encryption protocol. I know. Right. These are things that we have all done at one point or another. Hopefully when it comes to security, we've only done it in the context of learning how it works, throwing away our code and then reaching for a professionally written

[00:21:58] Matt Baker: and vetted library. Not always true, unfortunately. Yeah. This is a weasel one, man. Like, cause I think also if you like to program, chances are you have some opinions about the tools that you use, right? I think everyone develops preferences over time and you can walk into a situation intent on using that tool, or maybe like it's out of ignorance. Maybe you've only learned one tool. I know for me, I've done both of these, like where, you know, you know, one way to do it and that's the way you do it until you learn better. And even then though you get excited about, maybe you learned a new machine learning library or like you learned some great new way to write a react component. I know for myself, I like to apply those. And I look for situations to apply those. And if I don't check myself, I'm I'll take a, I'll take a small thing that would have been solved very easily and contort it, you know, to indulge myself a little bit. And then when I realized what I'm doing, I, I like to think I have the clarity to catch myself and back out. I definitely don't always, but yeah, this is probably going to be one that I have to fight my whole career. I'm sure. Yeah. Sometimes it's more obvious. Like

[00:23:06] Allan Stewart: we hear about resume driven development. Like, Oh, I want to use this cool tool because it's cool tool or, or even worse. It's like, well, I want to know this so that I can get another job, a better job somewhere else. And it doesn't fit the environment. You know, in a case like that, it might be easier to spot, but in a lot of cases, it's so subtle, you know, there's just elements of a solution or, or like you were saying, Matt, this is the way that we've done it before. This is the way that we've always done it. And so you just assume that that's going to be the thing again, without checking those assumptions.

[00:23:40] Dave Adsit: Try this justification on for size. We could solve the problem right now with tool X that we already know, but at scale, we'll need tool Y that we don't know yet. We should execute and implement with tool Y now so that we get good at tool Y by the time that we actually need it.

[00:24:03] Matt Baker: Like how often does this come up? Like, I think my blood pressure,

[00:24:10] Dave Adsit: I don't want to admit how many X's and Y's I could plug into that scenario, but I'm, I've got one in mind that you both are very familiar with. And it was a pretty big one. It made so much sense at the time. And honestly, in retrospect, we never really needed tool Y.

[00:24:28] Matt Baker: I'm sure like word for word, those sentences that come out of my mouth, like trying to argue for a tool, you know, like me too. Like there's so, you're so certain you're going to, you're going to hit this scale and it's going to be so rad. And no one in the room is being like, well, we're not at that scale yet. You know, like the, the big question, like, well, what scale are we at now? What's our anticipated growth? It's so tempting. And so learning, maybe this is just one that everyone has to make. I don't know.

[00:24:59] Dave Adsit: There's no way we can solve this problem without a Cassandra cluster. Certainly we could run right now on a single access database on one node, but obviously we, we have to get to a Cassandra cluster because at scale access doesn't work.

[00:25:15] Matt Baker: Yeah. I did this the other day on a system that has like five, five users, like single digit users. And I was load testing like 10,000 requests a second, like very abnormal traffic patterns, like, and then changing the code at times of not trivially in response. Like I just stepped back, like, what the hell am I doing right now? Like there's surely, there's other things that should be working on. This is not the biggest problem.

[00:25:44] Dave Adsit: It might've been the most fun problem in the moment.

[00:25:47] Matt Baker: It was, and it wasn't go. So, you know, just another shout out for go.

[00:25:53] Dave Adsit: So that kind of gets me thinking a little bit about one of the common failure points for me. This may not apply to the rest of you, but I have found that every time I've tried to estimate how long it's going to take or how much effort it's going to take to do something before I've done it, I'm, I'm just off by orders of magnitude. Sometimes I'm like the most pessimistic person in the room. And I'm like, I don't know, we'll never get this done inside of six months. And somebody is like, what if we just change this config file for like change this one line? And then the problem is solved, but more often it's the other direction. I'm pretty sure I can do this in one day.

[00:26:33] Matt Baker: Yeah. Like what a, what a big conversation. I don't know. I don't know if the conversations I don't do, I don't know. I don't know. I don't, I don't get into the social media stuff I did for a little bit, but so I don't know if it's still raging, but there was a time where like the estimates conversation was raging. What I heard referred to as the no estimates movement, which that was kind of funny. I think they have a lot of good things to say. Me personally, I tend to shy away from estimates, but I'll tell you, I have never in my life ever once been right about an estimate. I've given a lot. I used to do consulting. I used to do contracting. That was par for the course. And I've never been right about them. And they are always, always an inhibitor for the person doing the work. I should say like the person who's asking for the estimate, typically like they take whatever you say. And I kind of at face value and I think it makes them feel good. And, but they're just so damn hard to deliver on. I noticed for me, one thing that's given me a lot of empathy for is if I hire people for projects. So I hired someone to help me with my bathroom tile. I've been doing some home rental stuff, but that's bigger than I wanted to try. So I hired someone and like, do like a wall tile thing. And they came in, they estimated it. They estimated both dollar amount and time. They didn't change the dollar amount on me. The time went a little bit over, but I had nothing but like understanding for them when they, when I walked in and saw what they were working on, I saw them working all day. I know the things that the unforeseen obstacles they hit. And, and I just know how it goes like writing software. Surely it's different than putting on bathroom tile, but one way in which it's the same is that you don't know what you're going to run into. And when that happens, oftentimes, it changes your trajectory. And I had the same thing with some people that helped me install some floors. I don't know like how to crack this nut myself. Cause like I said, as the person paying for that work, I felt good when they said it'll take this many days and it'll cost you this much. And I was really appreciative that they didn't change the dollar amount, but the day, like it felt good knowing that it would be done at a certain time. And I had planned some stuff on the back of that and, and everything had to slide when it slid, but I don't know how I would have responded. Had the person just said, I don't know how to do it. I don't know how long it's going to take. Like if they give me a fixed dollar amount, I guess I'd be more okay with that. And I think that's what we're trying to do in software. And when I'm on the software side, I'm all for it. Like, I don't know how long it's going to take. Just let me get to work and I'll update you daily, you know, kind of thing. But we still do for some reason, people still ask for them, never been right about them. And oftentimes they like, I don't know, I'll shut up. I've been rambling, but I think there's just untold like knock on effects that come when you start missing estimates, especially habitually on a project that continues to drag.

[00:29:08] Dave Adsit: Well, so the thing for me is that an estimate is a potential solution in search of a problem. And the real problem that people have when they ask for an estimate, isn't do they want to know how long it's going to take? What they want to know is how much am I going to spend? When can I start getting value from this? And more often than not, I have found that in product development teams, which is different from consulting teams, right? We can't know because we've never done it before. But that's scary. If you're not the one doing the work, that's scary. So you want somebody to give you some confidence that it's going to get done. And the, one of the ways to flip that around is to say, okay, what are the most important things to get done? Let's prioritize and let's work on them. And then when we run out of budget or time or whatever, we will stop having known that we've started with the most important things that work backwards. To some extent that goes to the framework. How many people who purchase, purchase software product or software services have been burned by a developer who spent six months working on a framework that was going to make it really easy to deliver the product. And they never got the product. And all they got is this useless framework that they don't even know what to do with. And it may not even work. It probably doesn't work. You know, if you started framework first, it probably doesn't work. So I think the estimate is a proxy for something else, which part of the reason, we're so bad at delivering them is we're being asked to predict the future in a way that is. If you've never done a thing and you don't want to know what you're going to find, right. You don't know what you're going to see when you roll the log over and look underneath.

[00:30:54] Matt Baker: Yeah. I, and I think it's to an extent, it can be a matter of perspectives. Like I wish we had some strategy friends thinking of some people that like, I wish we had on the call with us right now to be able to talk about this because I mean, strategy is infamous for coming over. Right. it's kind of like saying something to the effect of, I know I'm not going to stick you to a date here, but can you ballpark how long this is going to take for me? Right. Like they're, they're trying to very cleverly ask for an estimate. And, and I get what they're saying because like from this, you know, if you work at a place that's got a strategy department, they're sitting there doing so many things that I don't know. But one of the things I do know they're doing is putting together roadmaps. Right. Where they say like, well, we're going to do these things. will take approximately this long. Here's the investment thesis. And I get why they need that. Like there's a whole school of thinking and way of working that is producing this need for you as the engineer to say, it'll take this long. The problem is it just doesn't work. Or maybe it works and I haven't figured it out. If anyone knows how to do software estimates properly, please tell me. But it's hard to say back to someone that's coming from that lens saying, well, I've got this chart, right? This project plan. And then you can see these little milestones here and this takes three months, then six months. And after, we only have 12 months of runway. So we need the project to be completed in here. And so it looks like it'll work, right? And like, I get it. I get what they're saying. But from the engineering perspective, like they're guessing, right? They're looking at it saying, I have no idea what I'm about to encounter. Like based on other things I've encountered, like maybe this, but like there's no, if they're giving you like a high degree of confidence, I just think they're lying to you. They're like, they're, they're, maybe that's a negative thing. I think that they're being too optimistic, right? So I just, from the developer's lens, I just don't know how to make estimates work. What I've started doing is saying, look, I'll give you an estimate. Fine. Let's say three months, but more than that, more than that, what I want to do is help you develop an intuition for how the project is going. Person who's asking me for the estimate. And the way we're going to do that is every day, I'm going to tell you how it went. And we'll do it until like, maybe it's every other day. You don't need the update every day, but every day I'm going to sit down at the end of the day and say, here's what, how it went. Here's the hurdles we encountered. Here's the progress we made, you know? And then maybe hopefully I can show them too, if I've shipped something, if you're working on that kind of project. But I've had more success with that. And I've started to try and like, use it as a tool to aid in the response to someone asking for an estimate, because like you want to be a professional, you know? And you don't want to just blow smoke at someone and say, it's going to take this long. When you know full well, that you have no idea how long it's going to take. But at the same time, like you want to portray confidence. It's a hard kind of like sticky point. If you're writing software for a living.

[00:33:43] Allan Stewart: You're going to put some of those strategists out of a job though, Matt. Part of the reason that they need a whole team, a whole strategy team, is that when the estimate is inevitably wrong, they have to update all of their Gantt charts. And you know, that takes time.

[00:33:59] Dave Adsit: Yeah. I just keep thinking that over-planning is one of the other ways that I have often failed. I'm going to do X and then I'm going to do Y and then I'm going to do Z and then A and B and C. And like X doesn't happen the way I think. And then it turns out that because of what we did with X, Z and C are irrelevant now. And we need to do Q, R and S instead. And they became higher priority than all of the other things. And so anytime I've tried to create these long-term detailed plans, it's just been a terrible waste of time. I keep thinking, I come back to the idea that, planning is essential and the plan is irrelevant.

[00:34:42] Matt Baker: It's true. Like, I feel like the reality of the situation is, look, we're going to show up every day and we're going to make a decision on what's the most important. We're going to work on that. Exert control over what's the most important. Like, let's get really good at that, right? Because I feel like no matter how much planning goes into it, that's what you're doing.

[00:35:00] Allan Stewart: It makes me think that there's something about planning that is the value. You're understanding the problem better. You're learning about contingencies and other things that could happen based on everything that we're figuring out and learning. This is what we think we should do, but you're at the beginning because that's what you do at the beginning when you're planning. Cause if you don't plan at all, then you're almost assuredly going to have a worse time, but it wasn't because of the plan. Like Dave was saying, it's because of what you learned and figured out when you're planning so that then when something comes up, you say, oh,

[00:35:34] Dave Adsit: we need to change gears now. I think that what you were saying there, Matt, is that every day you come in and work on the most important thing, the highest priority thing. I think that that's true in the ideal case, but I don't think that that's true in the average case. I think there's a lot of times where we come in and we work on, we work on the framework and we are working on parts of the framework that are never going to be used. And so that's why people keep asking us for estimates. I think that you're right. That's what we should be doing. We should. Do the planning to understand the landscape and the risks. And then we should use that as like a mental tool, mental model for executing on the highest priority items, but not be tied to this plan, this rigorous Gantt chart type plan. I also have never worked on one of those that panned out the way that it was supposed to. Even when the manager doubled the estimate and his manager doubled that estimate and her manager doubled that estimate, we still didn't get it done within the estimate. Because if you've doubled the estimate and created a buffer, well, that's where you just add a little bit of scope creep. Just a little bit.

[00:36:44] Matt Baker: Yeah. I think the map or the planning can be a good map for making that decision every day, right? Like what's the most important thing to work on today? And you can use that map. And I also think like not to steer us too far away here, but the whole concept of stand up and agile, I feel like was this. Like if you can get away from the. The ceremony and stuff, it's really just an opportunity to say, Hey, yesterday, you know, we thought this was the most important thing to go do. And so that's, here's what we went and did. Here's what we learned based on all that, you know, and then this plan, like you could just have your, your project plan up on the board and, you know, and based on that, what's the most important thing to do today? Somehow working that way and get kind of, I don't know if there's a way to work within deadlines that way. I guess there is, you just set a deadline and work that way, but I definitely know that the projects that I've worked on. I don't know if they were finished faster or slower. I don't know, planning introduced so much secondary work that has slowed it down in a remarkable way, but I do know that the projects just felt better. They were fun to work on. Morale was better. By embracing the volatility that we knew was coming and just being prepared to have type feedback loops and ask ourselves, you know, often what's the most important thing we were, um, we were effective. Uh, but like I said, I don't know if that was slower or faster than, you know, working under estimates. But it, you know, the team felt better, uh, than the people receiving the product felt better as well.

[00:38:11] Allan Stewart: Well, you're brushing right up against one of the mistakes that I made in the past. Uh, when I first learned about agile, it was in the context of scrum. And I saw all these things that were being taught about through a consultancy explaining these different ceremonies and things that are part of the processes of scrum, right? Uh, the ceremonies and meetings and whatnot. It seemed really appealing to me at the time. Especially compared to the way that we had been doing things, which just felt like the worst. So I scrummed so hard. What are you supposed to do? What is the formula? This is like physics class. If we just know the right formulas and you plug the right numbers into the variables, then inevitably you come up with the right answer and everything will be great. We're going to get the velocity chart, right? So we got to just get our t-shirt sizes perfect and our Fibonacci numbers. And we're going to lock those in and it's going to be great. It's going to take us a few iterations, but we're going to stabilize on our velocity. We're going to go through the backlog grooming. This is an important thing that we need to do because it's on the list of things we're supposed to do. And it was a miserable failure because it wasn't actually meeting any of our needs. There are principles behind these practices. Like, well, why are you doing this? Why are you holding a retrospective? And I had completely missed that. There's these three questions and I need everybody to answer the question for the retrospective, because that is the way that you retrospect. It didn't go very well.

[00:39:44] Matt Baker: Yeah. I'm sitting over here laughing, trying to lean away from the mic, but laughing. I relate, you know, and I can picture it. I'm having a thought now of explaining to someone planning poker and just the look of like, just kind of like the questioning. And they had on their face and me just not understanding why they couldn't see the value and planning poker. And if you don't know, planning poker is it's when you sit down and you're grooming it. Well, lots of ways to use it. The way we were using it, this place was grooming a backlog. We were going through and the backlog not 60, 70 items that we groomed every, I think, three weeks. It's tough. And we played planning poker in order to groom the backlog. And that's where you you assign a card size. It's an arbitrary. size to every item in your backlog. In this case, these are user stories and it's supposed to help you approximate effort and importance and just a few different things. But when you take that stuff super seriously, when you look at someone and say like, that's definitely not a three, that's a five, like you're being so silly. And I've done the same thing where I got so caught up in it, where I had like framework for what's a one, what's a three, what's a five. And we're going to play this planning poker. And at the end, it's going to be really good. And like all the while you're just totally missing adding value to the company, but you're inventing an interesting planning strategy and you just like, you cleave to it. For me, it was probably out of like fear of not knowing what to do. You get in over your head, you get into some of these positions and like, you might not, like you maybe got the job and maybe you got a little luckier. Maybe you are just having imposter syndrome and feel like you're not up to snuff. A process and something that quote unquote guarantee success. Boy, that's tempting.

[00:41:38] Allan Stewart: I've taken that pill before myself. In a similar vein, coming up with a way of doing things and trying to stick with it. Something you said earlier kind of reminded me, Matt, you were talking about having empathy for these people around estimates. For me, where those two combined in a bad way was code reviews. There's one time in particular that sticks out in my mind because I had come up with this process, I was learning all these things and they seemed really great and they, they matched up with what people were telling me. It's like, yeah, you should be doing unit testing, you should create clean code. And I read this book about clean code and here's a bunch of code smells and we shouldn't have smelly code, becuase, ew, stinky. And, you know, I came up with all these things and I tried to spend this time to, like, help my coworkers understand what it was that I wanted them to do, but it was, it was, like, this fever dream of my own. about like this glorious utopia of code that we were going to create. So we've gone over this who knows how many times. I'm not sure why they hadn't yet strung me up. Then I get this code review pull request one day, start going through it. Go, well, this doesn't fit the thing. And oh, here's a code smell. And I can identify it by looking at Uncle Bob's book and telling you the letter and number that goes along with this smell. And I was going through and it was making me mad. Dude, I've been telling you about these things for this long. I can't believe that you would just not do it the right way. I've told you what the right way is. And why wouldn't you do this the right way? The right way. The right way. Red flag. So, you know, I get into this and nitpicking on all of these things. And so by the time I'm done nitpicking, I just write this, just scathing. Summary comment. You haven't done any of the things we've talked about this. And what are you thinking? I can't believe that you would do something so terrible as this. And so I got to have a talk with my manager the next day. And the only saving grace really was just that I had been a really productive developer. I actually, luckily for me, was a good developer on the team and the manager. And the manager didn't want to jeopardize that aspect. Because if I was a bad developer, he should have kicked me right off the team. Just been like, you know, go find another job because I was just a jerk to that poor other developer. And it created, you know, a bad environment. It was no good. And it's, it's one of the ones that I regret most of the various mistakes. Like I don't, I don't so much regret breaking production for a few minutes. Oops. Okay. I'm sorry. That inconvenience is some people, but when I've personally hurt somebody that I know, it took me a while to recognize that that is what I had done. It haunts me.

[00:44:38] Matt Baker: You said fever dream. I wish we could subtitle this episode where fever dreams, because that's totally like such a good description for that mode. You were talking about where like the holier than now, and I'm not saying this towards you. I'm like from me, I really relate to the space dream. So you're talking about where you've got it figured out. The team just needs to listen to you and you've told them 20 times. Why aren't they getting it? Like you've never stopped to think like maybe they don't care. How could they not understand this? You know? And yeah, fever drink. What a great way to describe it.

[00:45:15] Dave Adsit: I've been in those situations before as well. And I've just thought like maybe if I just had a worse attitude that would help solve the problem. I got it. I got to the point in one job where I just, I had a bad attitude about the way the product was going, the way the project was going. And I just, I had trust issues with some of my coworkers and what they would deliver. And I just kept doubling down on this bad attitude until finally I basically rage quit the job. And then I was like, oh crap, now I need to go back and find a new job. Maybe if I just apologize that will make up for the last nine months of me having a terrible attitude. That should do it. Right? No. No, it doesn't. I regret the bad attitude that I brought and how it affected the team. And I regret burning the bridges with some of those people. They weren't in the same place when it came to designing and developing code that I was. But that wasn't necessarily their fault. I should have felt more responsibility for bringing them forward and teaching them and helping them rather than just ridiculing them. I regret burning those bridges because now I don't have the opportunity to influence them and help them in their career anymore now that I've grown up just a little bit.

[00:46:36] Matt Baker: It cuts both ways, right? Like there's surely ways that they could be helping you right now.

[00:46:42] Dave Adsit: Certainly.

[00:46:43] Matt Baker: Like the, especially in the software field, like your network, like we've been really fortunate that you can pretty much throw rock right now and get a job if you know how to write code well. But like, who knows how long that lasts? And you might have to fall back on, you know, what a lot of the industries do. Which is you build up a network over time. That's really valuable. And just smoking those bridges because someone won't write code the same way that, or write code really the way you want them to, even though the way they're doing it, you know, seems to be working and it's fine. Big mistake for sure. Just like, I want to put that up on the board and put my name to it next to it as well. It's just, you just get caught up in it, you know? And I don't know, Dave, all the things that played into like your, you know, your psyche when you got to that point. But I feel like for me, it's a slow burn. Over time, I'm just thinking, you know, the right way to do things and just being like indignant when people don't just immediately adopt your perspective. No. And I think that that can bring some bad things.

[00:47:37] Allan Stewart: You can throw that rock and hit a software job, but is it one that you even want? There's a lot of, a lot of places out there that work in ways that I would not necessarily consider as a craft or professionalism.

[00:47:53] Matt Baker: Agreed. I'm thinking about humility, Dave. With your. Yeah. Comment. Not being humble has surely like made it hell to work around me with certain people at certain times. I'm sure, you know, in my career and, but there's also, I've taken some actions due to a lack of humility thinking I could make code changes in certain ways. It turned out to be very like problematic. I was working at one company and I was on like a scrum hangover. I'd just come out of like a, like what Allan was talking about earlier, you know, like a very like ceremony or emphasis on ceremony. Scrum. ceremony, go fast and break things mindset. And so I just opened up what turned out to be like a core library and broken API and shipped it due to the project, the way it was all set up. Certain people shipped the same thing later. It was deployed anyway, just the way it was deployed. So I poisoned the pill that they ended up shipping to some of their customers as well. And it broke core stuff. And like all the customers called and were like, what the hell happened? And the CEO found out and was just, what the hell happened? And it all boiled down to me just saying, I don't know. I thought I could just make the change and figure it out. I thought it'd be okay. It was just dumb, just total hubris. It was in response to feeling like I had just graduated philosophically in software by ditching scrum. And so I was like, no more process. And then the whole move fast and break things. And it was such a stupid thing to do. And it was just cocky, just being cocky. Thankfully, we didn't lose any customers over it, but they called every single customer. Customer called that I knew of. They didn't have a lot of customers and they all called them. They were pretty pissed off. It's just being dumb.

[00:50:01] Dave Adsit: Man, I've had similar experiences where my arrogance has gotten in the way of solving the problem. I'm thinking back to when I was working on a software system for taking inventory in a restaurant. First of all, I mean, this is kind of a combination of several of these different types of problems. First of all, I had come up with a very elegant solution. from several different inventory points and when inventory had been introduced into the system, I could tell you how much you'd used over a time window. We didn't do inventory every day. We might not count every item, every inventory, but I could, if you said between this date and this date, how much of this product did I use? I could find the last time you'd inventoried it before the And I could add in all of the times you'd purchased it. And then the last time you inventoried it before the close of the window. And I could tell you, this is how much inventory you used. I was like, this is a really elegant solution. It's SQL based, so it operates on sets. And so you don't have to do it iteratively by walking through every item in the inventory, et cetera. So it was fast and it was super elegant. And none of my customers, wanted it. Every one of my customers wanted to say, assume I have nothing in my kitchen. Now I'm going to go count what I have in my kitchen. Tell me how much stuff I have. And I spent weeks trying to argue with my customers that I, as a software developer, who had worked in a kitchen as a line cook for a couple of years in high school, knew better how to run a professional kitchen inventory system than people who had devoted Now, I'm going to be Now, Now, Now, Now, Now, Now, Now, Now, Now, Now, Now, Now, Now, build the product that actually served the purpose. The thing about that one is that that was such a learning experience to me that a year and a half later, when I was transitioning the product to a new developer and I was leaving and I was like, so this is what they're trying to accomplish. And this is why. And I spent the last year and a half eating humble pie and understanding how they run these things. And let me tell you how this new feature needs to be built and what it needs to accomplish for the users. And the developer that I was handing it off to said, listen, I don't want to build that feature. I'm going to build this other feature that's way easier. And I'm like, it doesn't solve their problem though. So let's do what solves the user's problem. And he's like, yeah, I'm going to build what I want to build. And you just go on to your new job and you don't worry about it. And so I left knowing that the product was going through another iteration. the same kind of developer arrogance that I had potentially overcome for myself in that one

[00:53:25] Matt Baker: instance. And the cycle continues. Thinking about feedback loops. I definitely, like if I can get on a soapbox, if I have the opportunity, I'm in the mood. Chances are I'll say something about feedback loops. With good reason though. This is something that I feel like I've earned the hard, honest way in my career. The most common way this shows up for me is if you write code with me, I'm going to try and make you do TDD. I won't try. I won't shame you as much anymore. But I'll still make a strong case for it. But for me, that comes down to tight feedback loops. So Dave, kind of what you were just talking about navigating a user's need, you know, like you, you had a feedback loop on repeat in that particular scenario, right? And eventually it sounds like a click and you got it figured out. And then you're, I don't know who this person was, but I'm going to call him a patty one, because it makes the story interesting. The patty one was walking down the same road, ready to make the same mistake. You know, but a thing that's come up for me again, again, in my career, both in delivering a product and writing the product, I guess in those two instances, you know, if you're talking, if you're more on the product side of the shop and you're dealing with the customer, this applies just as much, I think, for the people that are building solutions for, you know, product need. If you don't have tight feedback loops, you're going to regret it. Like you might get lucky. Sure. Every now and again, someone's going to get lucky. But what I mean by when I say tight feedback loops on the product side, if you come up with a product idea, you better damn well, like be able to demonstrate that people want it. You know, like you, you want to be able to test the market somehow. And sometimes that does look like building something. But the way you build something in that situation matters. Like you're, we I've heard the expression build to learn build to earn. Sometimes that's not the case. Sometimes you're building to learn a thing. Other times you're building to earn money. And I think that applies here on the product side. You know, when you don't focus on making sure you're building the right thing, like it's a big risk that you don't need to take. And you can address that risk just by staying close with your customers. And sometimes it's hard. I, you know, to, it's not as easy as just saying, well, just phone up your customer and say, Hey, do you want me to build this thing? You know, it doesn't work that way all the time. Like you've got to get creative, but test your idea. If I can switch over to the code side for just a minute, when you're writing code, you're going to be able to test your idea. And you're going to be able to test your idea. And you're going to be able to test your idea. And you're going to be able to test your idea. And you're going to be able to test your I know everyone who's written code for a living will relate to what it feels like to write code for a few hours and then try to compile it and see that it doesn't work. Or maybe once you compile it, you run it and it doesn't do the thing that you've got to do. And now you've got like this four hour surface to go figure out what's going on. I kind of think it's a waste of money for your customer. I think it's not a total waste of money. You're going to get to where you're going anyway, but you can probably get there quicker and more cost effective for your customer. If you, um, you focus on feedback loops on the code side. I believe that if you write tests before you write code, you know, it puts you in a position where you're always asserting that the code you think you just wrote is in fact the code that you wrote. And so if you don't like TDD, you could do like REPL based development where you're just running it often, right? Like you write a little bit, run it, but not working in that way. And instead spending, I don't know how, like what the longest stretch I've gone. I know it's been multiple days where I've written code multiple days before trying to run it. Um, that stuff's just a fool's errand. And I wish I could go back. Cause I've sunk so much time writing code that way.

[00:56:51] Allan Stewart: Speaking of feedback and also humility. One of the mistakes that I've made in the past that I've had to learn the hard way is recognizing the importance of how I gave feedback. So, you know, something would happen on a job, you know, between some people, or there's some event that's going on and I would give feedback. And unfortunately I often would get myself passionate about it. And I have facts, data. I know I am right. And some of the times I think legitimately the thing that I was going to complain about, I think I really was right some of the time that it should have been different. But the problem I had was in the way that I communicated things. Sometimes it was, you know, because of that emotion, I'd want to lash out at people. It's like, why are you hurting us with doing this bad decision? Or I wouldn't think about the audience. Who is it that I'm trying to convince and how best can I convince them? Or even audience in terms of, are there other people? Am I going out to the public venue, standing up in the town hall meeting or, or proverbially doing that in something like Slack and just being like, you're wrong. It didn't work. And oftentimes there was other context. Yeah. All of my facts and data were there, but also incomplete and without the rest of the. The context of why I think was happening. I got myself in trouble on multiple occasions doing this kind of thing where, you know, I've got my righteous indignation on and I'm saying what I think needs to be said. But the way I'm going about it caused more problems and didn't ultimately solve any of the crusades that I was going on in the first place.

[00:58:40] Matt Baker: No, you go out, there's a number of books, right? Like, uh, thank you for arguing crucial conversations, radical candor. Surely. There's other. There's other ones. Like I can think of the book I read that emphasizes clear communication. And I took that and justified, you know, treating people like shit, you know, where like you, you like tact is a real thing, you know, maybe that's the mistake. That's the lesson here, I guess. But, uh, yeah, like you're saying, Allan, like you get the data all lined up and you see, you think you're right. And in some cases you're right. You know, and you walk up and you throw a brick at someone and then you're just amazed. It didn't go well. And it's hard because you feel on one hand, like, especially like with some of these books, they champion embracing the difficulty of giving critical feedback because it's ultimately a compassionate thing to do. But I think maybe what doesn't get as advertised as much as if you're trying to be compassionate, you know, because you're going to carry yourself in a certain way. If this is someone like you're trying to show kindness to, you know, versus someone that you're trying to like do a seemingly kind thing by giving them critical. Feedback where really you're just being a jerk. And I know I've done this and I felt even justified in like on the backs of some of these books where I thought like, well, I'm, I'm being the person that's giving feedback and telling them what they need to hear. Like, ultimately that's for the greater good. And like, I, whatever you can argue that all you want, but like, I didn't make a friend doing it. And maybe they took the feedback. They never, they never showed it to me that they incorporated it. And if I were them, I wouldn't have either. Maybe they took the feedback on somewhere else, but like it could have been. It could have gone so much better, just a little bit more grace and consideration for the human being on the other side of that conversation.

[01:00:24] Dave Adsit: And there's some component of context there as well. Right. If you stand up in the town hall and you say, I have a question. Our company strategy is really stupid. That's going to go over very differently. If you go to the head of strategy one-on-one and say, can you please help me understand ourselves? And then you can ask those critical questions like this seems to be making the assumption that blah, blah, blah. Meanwhile, we have evidence that the opposite of that is true. How did that come into play? So I think that there's a lot of context that can make some of those things better or worse, depending on how we choose to represent them. That isn't, you know, it isn't to say that you shouldn't be radically critical. You can't be candid and have crucial conversations. You need to in order to succeed in business and life, but you don't need to do so in a way that's aggressively antagonistic.

[01:01:32] Matt Baker: Yeah. You know, I think about another mistake on my mind that I think connects to this is not leaving bad jobs soon enough. I'm sure some people are great at this. I'm not one of those people. I think it's similar to like being in a bad relationship. You know, be that like a romantic relationship. Maybe it's a friendship. Maybe it's your neighbor. I don't know. But there are bad relationships that you can get stuck in. And sometimes you can't realize it for a little while. Right. And one, I'm glossing over a whole big subject here. What I want to say is that similar to bad relationships, there's this slow escalation of poor communication that occurs. I think where over time, like it's almost more about making someone look like an idiot or proving someone wrong, like scoring a point. And I don't think. It's straight on like that. I don't think that you're just showing up saying, I'm going to make this person look stupid. But like, it's usually we've had a ton of debates about this and it's gotten hostile. And so I'm going to take this opportunity to like take a jab. I'm going to take a shot at this person and make my point. Like you were saying with the company strategy and a really like funny, but in a way I've seen done where someone just stands up and says, I have a question. The strategy sucks. And like, there's probably a whole lead up to that. That caused him to say that there's probably a whole series of like bad conversations, bad encounters, bad decisions, whatever, that has caused that person to get to a point where they're just going to say this sucks. And I think it's one thing to watch out for is like, if you're getting there, maybe you should leave that job. You know, maybe it's gotten to the point where it's irreconcilable. I think that happens. Toxicity in the employment relationship can creep in. And sometimes you can't correct it either because it's just too much or you don't want to put in the work or I don't know. I'm not. I'm not. I'm not a psychologist, but I do know that I personally have stayed at jobs well longer than I should have because of the security, because of any number of reasons. And looking back, there are a few, it's kind of hard, right? Because you can't look back at your career and say, like, I wish that would have gone different because everything's brought you to where you're at right now. And so in that sense, I'm glad everything went the way that it did. But if the goal was to minimize emotional turmoil, one of the things I would say is, hey, don't stick around that bad job. Any longer than you have to. Once you realize it's gotten there, once you get treated that way or like you start treating people that way and you see it in yourself, hopefully, you know, at some point you are able to see that leave. If you can't reconcile it. I don't know. Maybe that's too strong of advice, but consider leaving if you're at the point where you're like being a jerk and you are having a hard time stopping.

[01:04:15] Dave Adsit: So one of the other. Mistakes that I've made in the past is. Designing or architecting a system that was just inappropriate to the problem. Often what it's turned out to be is that I've created a system that's too complex to explain or teach people how to work with or work in. It's just unfit for the engineering group. It may be an. Okay. Situation or an okay solution to the technical problem, but it's not a good solution for the staff that I have to work on the problem. I don't know why I do that. Sometimes when I'm halfway through the process and I identify that I am doing this again. I'm like, am I just trying to prove something to these people? Am I like, look how smart I am. I created a system that's so amazingly complex that no one can implement it. I don't think I ever set out with that as a goal, but sometimes I feel like I've, I've done that accidentally. Or I've created a system that's so complex that it addresses a whole bunch of risks that we will never realize in the course of the product and the company. Like, ah, but if this one thing were to happen, we've pre solved it. And people are like. Yeah, but what I'm trying to do is actually create a new page in our app that does X, Y, and Z. And I can't because your system is so complex that it's going to take me six months to do what should take me a week.

[01:06:02] Matt Baker: Yeah. This big nerve, big nerves being struck over here for me. I, uh, the way this shows up for me is designing a framework or a platform prior to the product. I don't know why we do it. Uh, I see people do it all the time. I've done it myself so many times. The thought process goes something like there are a common set of problems that everyone's going to encounter when trying to build a product. Therefore we should solve those now so that we don't have to spend time on them later or something different to the effect of like, well, we need to build 20 web pages. So if we build a framework that allows us to add a webpage trivially in a trivial way with like a DSL or something, or we make like the function of adding. I'm laughing because like, it's just such a stupid thing to say. Right. And it's such a stupid thing to think. And I've thought it so many times and I'm not, I don't mean to be rude to anyone that's thinking it now, but it's stupid. It's stupid because you're just wasting your time in what you've said. You've said like, it'll help us go faster to ship those features. My God, just go ship those. Features like just ship one of them. You know what I mean? Like, because even if you think, you know, all the features you don't like you're designing for a finite set and the set is not a finite, like it's going to change on you all the time. And I can't tell you how many startups I have stock in that fail because I've gone and worked at them and they will pay in stock. Okay. Right on. What are we doing? And they're like, well, we're building the platform because we think it'll help us ship the features quicker. And I'm like, yeah. You know, like a few times I've got, uh, I've gone along for the ride. I've also said done it myself. Like surely a mistake I've done so much, but I, this is another one that like shows up for me so much that it's almost cliche. You know, when you see people, I don't know what you call this anticipatory engineering or what, but, um, it is a real thing where people set out to design the system before using the system or design the system before building the product or design the architecture. Like I've done the same thing. You just mentioned day, like get out your whiteboard, get some coffee and like, oh boy, everybody's screwed. Right. Because you're good.

[01:08:25] Dave Adsit: Listen, if, if there's a problem that can't be solved by an event driven microservices system with a single page app on top of every event, every, every microservice, then I don't know what that problem is. I mean, at the very least that solves the problem. Of we don't have enough highly paid architects on the team and we all need to feel good about our big brains.

[01:08:52] Matt Baker: I wonder if we could like make some like tech horror movie out of this for like the impressionable child goes to Q con and like sits in the architecture track. Comes back and drives you right off a cliff.

[01:09:08] Allan Stewart: I think it's interesting that in a lot of these cases, one of the core problems is that we build up in our mind. This expectation of correctness. Oh, this is right. This is good. This is the way things ought to be. Whether it's the technical solution, whether it's the interpersonal relationship that you were talking about before Matt, where it's like, it's not so much that you're trying to point out that they're a jerk, but obviously they're a jerk. They're bad at their job. Because that's the story that you've told yourself until you believed it. And that, that these lies that we've told ourselves then drive into these bad behaviors that we really regret later.

[01:09:45] Dave Adsit: What you've got me thinking about is that patterns are not designed. Patterns are observed. Frameworks should not be, they should not precede the product that they are delivering. They should be extracted from several successful products. When you've built something like, I like the rule of three because it's easy to remember and it's simple enough. And it's like two could be a coincidence, but three might be a pattern. Maybe. If you've built the same thing three times. And you've ended up building the same things to build it three times. Maybe that's the core of the framework that you should extract. But until then, oh, you are so right. You are just wasting time. Every time I've tried to design a system to predict what direction we're going to go as a, with the product. It's been, it's been a disaster. And I ended up having to unwind a bunch of code and recreate things in a way. That allows me to build what is actually needed. It's just so costly in terms of time. And even worse in terms of ego. If you get convinced that you designed it right the first time, and now you're like twisting your framework and refusing to build features because they don't fit within the framework. It's, it's just, you're doing a disservice to yourself and your product, your customers and everybody involved. If you can observe a pattern and then extract a tool. To make future implementations of that pattern easier and better. That's a good thing. But if you just preemptively design a pattern thinking that you're going to run into it. My experience is that I am no better at estimating which software framework features I'm going to need than I am at estimating how long it's going to take me to build a feature.

[01:11:40] Matt Baker: Patterns emerge. That's the thing I'm taking away from that. I think that's such a clever way to say it. Yeah. Patterns emerge.

[01:11:47] Allan Stewart: Well, I think we'll wrap up our discussion there. Mistakes happen. We're all going to make them. The important thing is that we learn from them. We try and make ourselves a little bit better and try to avoid the pain. Hopefully some of these tales give you something to empathize with as a listener, or, or maybe we'll help you to avoid a painful situation in the future. But for now, we're going to recommend that you join up with a community of professionals. By attending a software crafters group or meet up near you. Here in Utah, the Utah SC group at utahsc.org meets the first Wednesday of each month in Draper, Utah. Maybe we will commiserate our mistakes with you there.