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?

[00:00:56] Matt Baker: Okay, yes. When I think about times that I've failed, I'll start with a, like, 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, it was a system that, due to its, any number of reasons, it was, became under, like, 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, a drop 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 When I tell that story today, I think, like, 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. Change 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 it. It would have been nice in the moment. Um, the, what I champion most now is, um, 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 method.

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

[00:03:30] 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 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 in production, but, um, 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 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, 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, uh, 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. This is fine. I'm just dying over here. You know, 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 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 up all the available connections. And so other parts of the system that needed to use Redis couldn't. And so they went down. 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 We 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 think that this may be apocryphal, but I have heard that at one point after the book Thinking Fast and Slow came out and 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 SonarQube, although that was back in the day where it was just called Sonar, I think. StyleCop, 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? And 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 I was working, I got very gung-ho about setting up these barriers. If you try to commit code, we've got a, I think we were using Subversion. It was before Git. And so there was 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 all I really ended up doing was just pissing off my 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 StyleCop enabled. And at one point in retrospective, we decided we would run a two week experiment where we turned turned it off just to see how that impacted our code quality and our ability 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: I think I, so I've been the subject to these rules myself. And then I've also been the person making the rule, looking back on those situations. I, one thing I wish I could just go back and whisper to myself back then would be something along the lines of, "Are you chasing the right problem?" I get why these tools exist. I see, I do believe they have some intrinsic value. I also think it's overblown a little bit, and I get why people reach for them, because it's a, 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, and I think these are especially powerful in the security area. Like if you're about to ship out like a, maybe a cross site vulnerability or maybe a, you know, like 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 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. It's just a 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 passive aggressive way. Yeah, they were involved with the creating 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 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 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 who'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 all of their public-facing APIs and libraries, et cetera. And so there is very high value in 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. I think about one of the podcasts that I like to listen to is Words and Numbers. And 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 on you. And everybody is happy about it because they couldn't have an argument. There was no argument to be had. Agreed. The decision was made. You either code and go, they'll 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 any 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. And I probably still do it. This is such a hard thing for me not to do, but 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, that was a big, big buildup to not even have a good solid example.

[00:17:54] Dave Adsit: Give me just, well, I've got one for you. Okay.

[00:17:56] Matt Baker: Okay, Dave, you go.

[00:17:58] Dave Adsit: Event-driven service bus. If you start out with a service bus as 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? "Well, I don't know yet, but I know the solution is event-driven microservices." 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 right there is the problem. I had this pattern that I really liked. And so I started looking around like, "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 in my career, I started to notice this too, when I build features into applications. Like if I'm working on an application where I have some leeway to put a new feature into it, like I'll want to be building this feature. Shirt and talk, I'll, 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. And like, never once did 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 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 merce ways. I've, I've gotten pretty good at spotting it in code. 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 sometime 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, more painful it gets.

[00:20:40] Dave Adsit: Yeah. There's that kids movie with Robin Williams, Robots. Find a problem, solve a problem, find a solution, apply the solution. Does it have the same ring to it? But man, we do, we do run into that a lot.

[00:20:55] Matt Baker: Yeah. I'm of the conclusion now that, like, there's a big people element to this problem where you just forget to get outside of your own head a little bit. You know, you forget to, like, pull someone that's not on, like, the, this idea is great train and be like, "Hey, can you just tell me if this is, this makes sense?" You know, you forget to get those feedbacks.

[00:21:14] Dave Adsit: Well, and I think 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 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 and vetted library. Not always true. Not always true, unfortunately.

[00:22:04] Matt Baker: 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 learn 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 realize what I'm doing, I I like to think I have the clarity to cash myself and back out. I definitely don't always, but 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.

[00:23:06] Allan Stewart: Like we hear about resume driven development. I want to use this cool tool because it's a cool tool, 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:04] Matt Baker: How often does this come up? Like, I think my blood pressure just went up.

[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, they're so, you're so certain you're gonna hit this scale and it's gonna 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, both?" It's so tempting and so learning. Maybe this is just one that everyone has to make. I don't

[00:24:58] Dave Adsit: know. "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 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 that has like five users, like single digit users. And I was load testing like 10,000 requests a second, like very abnormal traffic patterns. And then changing the code at times, not trivially in response. I just stepped back like, "What the hell am I doing right now? Surely there's other things I should be working on. This is not the biggest problem."

[00:25:42] Dave Adsit: But 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 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 big conversation. I don't know. I don't know if the conversations, conversations I don't do Twitter. I don't, I don't get into the social media stuff. I did for a little bit, but, um, 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's 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's par for the course. And I've never been, and write about them, and they are always an inhibitor for the person doing the work. I should say, like, the person who's asking for the estimate, uh, 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 on stuff, but that's bigger than I wanted to try. So I hired someone to do a wall tile thing. 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 understanding for them. When I walked in and saw what they were working on, I saw them working all day. I know the things, the unforeseen obstacles they hit. And I just know how it goes. Writing 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 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 long it's going to take." 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. "I don't know how long it's going to take. Just let me get to work and I'll update you daily," that kind of thing. But we still do, for some reason, people still ask for them, never been right about them. And oftentimes they, like, 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 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 and work backwards. To some extent, that goes to the framework. How many people who 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. 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 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: underneath. Yeah. 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, and 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 very cleverly asked for an estimate. 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. We'll take approximately this long. Here's the investment thesis." And I get why they need that. Like 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 you can see these little milestones here. And this takes three months, then six months. And after, you know, 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. Yeah, 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. Or, 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 I'll 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, it's a hard, kind of like, a sticky point if you're writing software for a living, you're

[00:33:43] Allan Stewart: going to put some of those strategists out of the 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. Yeah, I, I just keep thinking that

[00:34:01] Dave Adsit: 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, 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. 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. Let's get really good at that. 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. Because 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 There's a lot of times where we come in and 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 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 know, 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, uh, like, if you can get away from the ceremony and stuff, it's really just an opportunity to say, "Hey, yesterday, you know, we thought this 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 if planning introduced so much secondary work that it slowed it down in a remarkable way, but I do know that the projects just felt better. They were funner to work on. Morale was better. By embracing the volatility that we knew was coming and just being prepared to have tight feedback loops and ask ourselves often, "What's the most important thing?" We were effective. But like I said, I don't know if that was slower or faster than working under estimates, but the team felt better and 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. 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, 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 with the right answer and everything will be great. We're going to get the velocity chart right. So we've 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 and 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 of, like, "Well, why are you doing this? Why are you holding a retrospective?" And I'd completely missed that. And it's like, "Well, there's these three questions that 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, I'm sitting over here laughing, trying to lean away from the mic, but just laughing. I relate, you know, and I can picture, I'm having a thought now of explaining to someone planning poker and just the look of, like, uh, it was kind of like the questioning look they had on their face and me just not understanding why they couldn't see the value in 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. Uh, we were going through and the backlog, backlog, 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 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 it's just 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, 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 know, you're, you're inventing an interesting planning strategy and And you just, like, you cleave to it. Right. For me, it was probably out of, like, fear of not knowing what to do. You know, you get in over your head, you get into these, some of these positions, and, like, you're, you might not, like, you maybe got the job and maybe you got a little lucky, or maybe you are just have imposter syndrome and feel like you're not up to stuff. And a process and something that, quote unquote, guarantee success. Boy, that's tempting. I've taken that pill before myself.

[00:41:41] Allan Stewart: self. And 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 matched up with what people were telling me is 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 because it's stinky. And 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 like this fever dream of my 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 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. Red flag. So, you know, I get into this and nitpicking on all of 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 been a really productive developer. I actually, luckily for me, was a good developer on the team 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, "Yeah, 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 out 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, out where, like, the holier than thou, and I'm not saying this towards you, I'm, like, from me, I, I really relate to the space 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. Yeah, fever

[00:45:12] Dave Adsit: drink, what a great way to describe it. I've been in those situations before as well, and I've just just thought like, "Maybe if I just had a worse attitude, that would help solve the problem." 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 about my coworkers and the product we're working on. 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. Certainly. 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'd 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. That 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 and just thinking, you know, the right way to do things and just being like indignant when people don't just immediately adopt your perspective. 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 places out there that work in ways that I would not necessarily consider as craft or

[00:47:51] Matt Baker: professionalism. Agreed. I'm thinking about humility, Dave, with your comment. Not being 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 install where efficacy be damned, like, you do stand up this way at this time, you do your burndowns this way at this time, you know. And so I was definitely in a buck the system mode or process be damned, you know, and I was working at a place where I needed to make a change to an assembly, or, excuse me, a DLL, you know, a .NET package. And it was hard to get the change done. People that knew about, like, how to make the change were dragging their feet. And I was in the "screw 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. You know, there were, 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 then, like, all the customers called and were like, "What the hell happened?" And the CEO found out and it's just, "What the hell happened?" And it all boiled down to me just saying, "You know, I don't know. I thought I could just make the change and figure it out. Like, I thought it'd be okay." It was just dumb, you know, just total, like, hubris. It was in response to feeling like I had just graduated philosophically in software by ditching Scrum, right? 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 called that I knew of. They didn't have a lot of customers and they all called and they were pretty pissed off. 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 to taking inventory in a restaurant. And determining 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 start of the window. 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, etc." 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 how to run a professional kitchen inventory system than people who had devoted their life to this pursuit. It didn't, again, it didn't cost us any customers. It just wasted a bunch of time and frustrated a bunch of people. And at the end of the day, the person running the product said, "You can keep your report, just build the one that they actually need as well." Smart product person, smart person. 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 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 of the same kind of developer arrogance that I had potentially overcome for myself in that one instance.

[00:53:27] Matt Baker: And the cycle continues. Thinking about feedback loops. I definitely, like, if I can get on a soapbox, if I have the the opportunity. I'm in the mood. Chances are, I'll say something about feedback. 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 that 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, uh, 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, uh, I don't know who this person was, but I'm gonna 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, um, a thing that's come up for me again and again in my career, both in delivering 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 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, 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, 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, if you focus on feedback loops on the code side, I believe that if you write tests before you write 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 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 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 a thing 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 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 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, like, tact is a real thing, you know. Maybe that's the mistake. That's the lesson here, I guess. But yeah, like you're saying, Allan, like, you get the data all lined up, you see, you think you're right. And in some cases, you're right. You know, 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 I've done this and I felt even justified, and, 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 gone so 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 and say, "Can you please help me understand our strategies so that I can be aligned with it?" And then 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 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 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, like, in 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, 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 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 an 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 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." And 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, and you, you know, are having a

[01:04:13] Dave Adsit: hard time stopping there. So one of the other mistakes that I've made in the past is designing 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 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, including you dumb dumbs." I don't think I ever set out with that as a goal, but sometimes I feel like 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 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. Big nerves being struck over here. For me, 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. 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 webpages. So if we We build a framework that allows us to add a webpage in a trivial way with, like, a DSL or something, or we make, like, the function of adding a webpage systematized in the system prior to building those 20. It'll go so much faster and we'll get so much stuff done." 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 finite. Like, it's going to change on you all the time. And I can't tell you how many startups ups 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? 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, 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, Dave, like, get out your whiteboard, get some coffee, and, like, oh boy Boy, everybody's screwed, right?

[01:08:24] Dave Adsit: Listen, 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 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 QCon and, like, sits in the architecture track and then 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're 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 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, 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, 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 with the product, it's been a disaster. And I end 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 like twisting your framework and refusing to build features because they don't fit within the framework. You're doing a disservice to yourself and your product and 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. 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 maybe will 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.