Chances are, as a developer, that recently you have done something that you're not very proud of. This happens to developers and probably everyone else. I know for a fact that I have experienced this, and many of my coworkers throughout the years have experienced this as well, the idea that you wrote something you kind of knew you shouldn't have written. But something competed for that attention, something competed for your best efforts, and instead you chose to go with something less than your best effort. And a lot of the time what we use to justify this is this concept of value or business value. The easiest solution, the one that works, the shortest pathway to functionality. Among this is an important thing to keep in mind. There's also risks to this. And that's what we're going to talk about on today's episode. My name is Jonathan Cutrell and you're listening to Developer Tea. My goal on this show is to help driven developers like you connect to your career purpose so you can do better work and have a positive influence on the people around you. This is a very practical and short episode of Developer Tea. We don't have a sponsor in lieu of the time that you would spend listening to a sponsor message I encourage you to take a moment and either leave a review or subscribe. And for those of you who are feeling particularly ambitious doing both, this is the best way to help Developer Tea. Reach other developers like you who want to listen to these ideas, these thoughts, and perhaps more importantly, take those kind of seeds of conversation and talk about them with their coworkers. So if you want your coworkers, for example, to be able to have these discussions with you, then perhaps the best way to help them do that is to give them a link to this podcast. So we want to talk about this idea that we take these shortcuts and what can happen as a result of this. And very often we do this for the kind of in the name of speed and the name of MVP and the name of working software. And this perspective is often kind of antagonistic towards the more craftsman style of software development. And in fact, neither of these have to necessarily be in conflict with each other. And before we dive in and talk about how to think about these kind of quick fixes in a better, more effective way, I want to take a moment and talk about what we're going to do without medicine. Medicine is used for a variety of effects. And if I told you that I had a substance that would improve your mood and give you more energy, make you feel more relaxed and be able to communicate better with other people, then it may sound like a miracle drug. It may sound infeasible that I would have something like this. But as it turns out, I just described some of the top effects that cocaine has in people. And if I describe to you a substance that would cause nausea, stomach pain, loss of appetite, itching, rash, maybe even a headache and jaundice, you probably think that you want to avoid this, perhaps at a great cost to you. But as it turns out, you probably have this substance in your pantry or something like it. And that's because it's Tylenol. And so this may not be surprising to you. Hopefully it's not that surprising that these substances that we've gotten used to, they have various effects that in a given small view context could be a good thing or in a given small view context could be a bad thing. What we do know about medicine and in a moment, we'll talk about how this applies to your code, is that only taking a zoomed-in view and disregarding the whole picture can lead to pretty detrimental effects. And this is true in our code as well. Just because we find something that relieves us, that works for this particular problem, and especially for just today's problem, does not mean, and this is the key factor for today's episode, that doesn't mean that that is a good decision. And the reason for this is very simple. What we do has complex effects. Very seldomly do we only have good or bad effects. Very seldomly do we only have a positive sense of value creation in what we do. This is very simply referred to as a trade-off. And unfortunately, very often when we make decisions about software, especially in small problems that we're trying to solve for the small problems, very often we view, our decisions as either good or bad. It's very much so this fallacy of black and white thinking. And so we can justify making poor decisions without really evaluating the cost of those decisions, the trade-offs of those decisions, because we see that the decision has a positive value to it. This is very similar to hearing the good effects of cocaine and just accepting it. Of course, perhaps it's not that detrimental. Maybe it's more akin to hearing the positive benefits of taking Tylenol when you have a headache and then ignoring the potential side effects. Now, we're really going to stretch the metaphor here for a second, but if you take too much Tylenol, eventually that can be harmful. And this is true when you take too many shortcuts and programming as well, but beyond that, what we need to be doing when we make decisions like this, this is the way to handle this problem. If you want to take notes, this is the time. What we need to be doing is even in these small decisions, consider the trade-off very seldomly. Do you make a decision that doesn't have a downside? You should be able to identify the downsides, even if you are just gaining intuition for what those downsides are. And then also retroactively, take a look at the decisions that you've made in the past, let's say, week. Short enough in the past that you can remember the decisions that you made and you can tie some of the negative effects that those decisions had, but look back and try to understand not only the good, not only the positive outcomes, but also the negative outcomes. This can help you create a better picture of your decision making as it relates to the accuracy of your decision making model. And what does that mean? We simply will break it down. Your decision making model is you making bets against the world. It's you trying to understand reality enough so that you can make a good decision, one that is beneficial, that takes you closer to your goals. And if you try to get closer to your goals and you move further away, that could be attributable to luck or bad luck in that scenario, but it could also be attributable to a bad decision. So it's important for you to look at your decisions and try to update that model of the world, your decision making model. And over time, what you'll realize is that you start making new, better decisions as you understand the drawbacks. If you only look at your decisions in terms of the, quote, business value that they provide, then you're ignoring the downside. And unfortunately, most of these things don't exist in a bubble. That has two effects. One, it makes it very difficult to always know cause and effect. This is really, if this was easy, then we would all be able to make good decisions a whole lot easier. But the other effect that this can have is that as you make decisions back to back, they kind of have this interaction effect. So if you make many shortcuts in your application, just like we were talking about with taking too many Tylenol, you may end up having more compounded effects, rather than having kind of a linear curve of of bad in your application, one bad decision or one shortcut paired with another shortcut could have a more of like a multiplicative effect. So the takeaway is very simple for today's episode. When you make decisions, especially in particular, especially when you are conscious that that decision is a shortcut, that it is somehow kind of lowering your standard in order to, you know, make ends meet. Be certain that you are aware and that you validate the downside of those decisions. As you validate the downside of those decisions, eventually, you should be able to draw the line. This will help you understand when this next shortcut that you might take is too dangerous. It's an irrational decision. It's a bad decision. It's one that could end up crippling the business that you're running or the software that you're trying to develop, and ultimately, instead of taking that shortcut, you can make a better decision. Thank you so much for listening to today's episode of Developer Tea. Once again, I encourage you to subscribe in whatever podcasting app you use and leave a review. I love to read the reviews because I love knowing how the show is landing, how we're doing. You know, given honest review and let us know both what we can do better, but also the things that you enjoy about the show, and this is going to help other developers like you find Developer Tea and decide if they want to listen as well. Thank you so much for listening and until next time, enjoy your tea.