What does it mean to make a good decision? I don't mean having a good decision framework, weighing all the pros and cons. I don't mean following all of the advice that you've heard on the show before or that you've heard on other shows about making the best possible decision in the given circumstance. Certainly, all of these things are still important to consider. They're still valid. I'm not throwing those out, but I'm asking, what does it mean to make a good decision? That's what we're talking about in today's episode. My name is Jonathan Cottrell, and you're listening to Developer Tea. Really, what we're asking here is, what is a good decision? It's very difficult or perhaps impossible to judge a decision in isolation. In fact, what a good decision is, is ultimately entirely dependent on context. That context goes beyond simply what are you trying to achieve with that decision because in context, many decisions can be a part of a pathway to an outcome. Let's break this down. Let's imagine for a moment that your goal outcome is clean, maintainable code. This is a valiant effort that many of us as engineers, we strive to achieve. In this circumstance, is it ever okay to choose to write code that isn't well-tested or doesn't employ any good design principles? If you answered no to that, that it's never okay, well, stick around because there are plenty of opportunities where this would be fine. For example, if you were sketching out an idea, a proof of concept, maybe if you're writing a one-time script, or maybe if you're planning to iterate on that particular piece of code and you have a plan in mind, you have a situation where writing that particular piece of code is acceptable. All of these can fit into a strategy that still leads to an outcome of good decision. At the same time, you may want to consider bringing your evolution evolution evolutionally and bringing evolution evolutionally to the evolution evolution evolution evolution evolution architected, maintainable code. In the same way, let's say that you have an outcome. Your goal outcome is to be healthy. Well, if you look at the decision of what you should eat in a given situation, a given circumstance, let's say your choice is to eat ice cream or not eat ice cream. Assuming that you agree that eating ice cream is detrimental to your health, it's detrimental to that particular outcome goal, it might be tempting to say ice cream is off limits. You're outlawing ice cream. This no tolerance policy is attractive because it directly follows the outcome and it's easy to implement. We never have to weigh that decision again. These kind of binary decisions, they are satisfying to our brains, but they're not always the most practical solution. Is there a likely pathogen? To the outcome of being healthy that includes eating ice cream? Almost certainly because that one decision, even on a daily basis, that one decision is not sufficient to meet the outcome that you're talking about. The scope of that decision, the frame of that decision is much larger. The critical thing to understand here is that at a small enough frame, each decision becomes incredibly clear, but the outcome is not sufficient. The impact of each decision is limited. Choosing not to eat ice cream one time is not going to improve your health in the long run. Similarly, if you go too wide, the context becomes nearly impossible to calculate. What is the impact of my singular decision on the entire span of my life? This is extremely difficult to think about. So instead, what makes more sense, in most cases, is to limit the frame. Not too small, not talking about that one time you ate ice cream, but also not too big either. Maybe the frame here is instead of one day or 60 years, we're talking about something more like a week. What this allows you to do is begin to make decisions together. Batching your decisions and weighing them against each other allows you to push and push. The critical concept here is that your decisions, when framed correctly, when you're thinking about the correct level of context, your decisions can be weighed against each other. So you make decisions not in isolation, and not with an overwhelming kind of mountain to climb or overwhelming amount of calculation to see how much that one decision affects the overall picture, but instead as a small collection. This collection should balance itself. As it turns out, this is one of the reasons why iterative work works out so well. The decisions we make in a given, let's say, two-week sprint, for example, we can think about as a collection of decisions. One decision can be weighed against another within the same sprint. Things in an isolated context are difficult to understand in terms of their impact, and things in a global context are difficult to understand in terms of their impact as well. The work to be done here is choosing your batch size. What exactly is the batch size that you need to choose? In some cases, those small isolated ways of making decisions can be helpful. There's nothing to be afraid of. There's nothing to be afraid of. There's nothing to be necessarily wrong directly with isolating to one decision. For example, if you're trying to build a habit, then isolating to a day-by-day decision-making helps you feel less defeated whenever you miss a day. And when you're making a long-term decision, like let's say purchasing a home, you may need to do a little more work to understand that longer-term picture, the bigger frame. Choose the batch size that helps you reach the outcomes that you care about. Another good illustration, another good metaphor of this is getting directions. Let's imagine that you're getting directions for a cross-country trip, and that cross-country trip maybe has 150 or 200 different turns in it. Well, it doesn't really make sense to just look at each next turn because what happens if two turns from now, the turns happen fairly quickly? Or perhaps there's a long stretch of road and you could run out of gas. Having some kind of context of what's coming up next, a little bit beyond just the next step, may help you prepare. With that said, you probably don't need to load into context the entire trip. Balancing between that kind of microscopic vision and macroscopic vision, somewhere in between, is likely going to be an optimal place for you to batch your decisions. What this means is that a good decision, in one kind of contextual batch size, may translate to a bad decision in another contextual batch size. If you're thinking about buying a house and you only do kind of budget calculations for the next five years, then it may seem like a good decision. But if you start doing budget calculations for 15 or 20 years out from now, you may change your tune, or the flip-flop may be true. You may notice that the five-year plan seems really difficult, but over time, the 30-year plan tends to work out. If that's the case, then you have a different argument. You have a different decision calculus when it comes time to actually make those decisions. Ultimately, it's important to understand that batching these decisions is something that should be done intentionally. What you're trying to do is see how one decision has an impact on another decision. The inputs to a given decision may be the outcomes of other decisions that you've made within the decision. So, if you're thinking about batching your decisions, you may want to batch. Thanks so much for listening to today's episode of Developer Tea. Hopefully, you enjoyed this episode. We always talk about things like decision-making on this show and plenty of other topics that you may be interested in if you want to become a better engineer, a better leader, a better person. So, if you enjoyed this episode, please subscribe in whatever podcasting app you're currently using. And if you really enjoyed it and you want to continue discussions like this with other engineers beyond the show, come and join our Developer Tea Discord community. Head over to developertea.com to get started today. Thanks so much for listening. And until next time, enjoy your tea.