Balancing Decision Frames

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 Cutrell and you're listening to Developer Tea. Maybe 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 for a minute. 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. So 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, we'll 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, clean code, of well-designed, well-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-limit to your 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. It's kind of binary decisions. They are satisfying to our brains, but they're not always the most practical solution. Is there a likely path to the outcome of being healthy that includes eating ice cream? 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 impact of each decision is limited. Having not to 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 made 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 pull, balancing your decisions so that the one day that you have ice cream, you can balance later in the week with a bit of extra exercise or maybe a slight calorie cut. 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 decline 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 necessarily wrong directly with isolating to one decision. For example, if you're trying to build a habit and 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. In 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 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 same 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. If you enjoyed this episode, please subscribe and 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. And don't forget to go to developertea.com slash discord to get started today. Thanks so much for listening and until next time, enjoy your tea.