How do you plan for the future? This is an intentionally broad question that comes into play every single day in our work and our personal lives. We plan both at the microscopic level, what we're getting ready to do in a moment or two, but then at a much higher level. We plan on our days, our weeks, our months, even to our years, and beyond. One of the unique aspects of being human is that we have the capacity to think in the very long term, even beyond our own lives. For the sake of today's episode, we're going to ignore the microscopic immediate scale planning because a lot of our actions are somewhat involuntary. Instead we're going to talk about the things that we are actively choosing to do with our time, but perhaps more broadly, we're talking about the process of planning in today's episode. My name is Jonathan Cutrell, you're listening to Developer Tea, and my goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. You've probably heard this phrase before, the best laid plans of mice and men often go awry. This actually comes from a poem written by Robert Burns back in 1785. I had to Google that. But this phrase and this feeling is something that we as developers and just as humans, we know this is the case. We had expected things to go one way and turned out they went a different way. And in fact, we can kind of feel this. If we look back over our past week, we can think what did we expect to happen and what things didn't we expect to happen? What things were totally unexpected that we could never have planned for in the first place. On a more grand scale, you can think back ten years ago, trying to put yourself in the mindset of where you were ten years ago, and where you expected to be. And depending on what stage and life you are, the difference between those two is likely quite large. And in fact, research has shown that people expect that the next ten years on average is going to be more stable than the last ten years. This idea that we've somehow and some way arrived at the present moment and that the present is what will continue on into the future for some indefinite period of time. Perhaps this is one of the driving kind of reasons that we continue to plan. We continue to make plans as if we know what that future holds. Interestingly, if you look at the average plan, let's say for a software project, the average plan tends to lay things out in some logical format. We have some list of requirements and we try to reasonably estimate how we're going to accomplish the software needed to meet those requirements. We lay it out on a timeline. We all get in a room and we look at the timeline, we sign our names next to it, and then fast forward to the end of that timeline, things look different. What causes us to continue making these same kinds of timelines and then seeing them fail? And how can we describe this bad mental model of planning and then replace it with a better one? That's what we're going to talk about right after we talk about today's sponsor, Lin-Ode. You can get a $20 credit just for being a listener of Developer Tea and get started on Lin-Ode today. Lin-Ode has native SSD storage, a 40 gigabit internal network and industry leading processors. Their enterprise grade hardware, S3 compatible storage options, and their next generation network means that Lin-Ode provides the performance you expect, at a price that you don't expect. In fact, NANDED plan start as low as $5 a month, that's going to get you root access to your server along with API access. This is a version four of the API. They've been doing this for a while now, and they have a Python CLI. So you can do all of the things that you'd love to do to automate your server management. It's a very developer friendly workflow, and that's because Lin-Ode is built by developers. In fact, they're hiring. If you'd like to check out the jobs that Lin-Ode has available for developers like you, head over to Lin-Ode.com slash career to find out more. Or if you'd like to get started with a new Lin-Ode account and $20 worth of credit, head over to Lin-Ode.com slash Developer Tea and use the promo code Developer Tea 2020. That's Developer Tea 2020 when you check out. Thanks again to Lin-Ode for sponsoring today's episode of Developer Tea. The topic of planning is not new to this show. We've talked about things like the planning fallacy, which is fairly well researched at this point. The idea that our plans are almost invariably underestimating the amount of time necessary to do something. And that the reason for this, very often, is that we underestimate the prevalence of random events, things that might keep us from achieving those plans. We don't plan for people being sick enough as an example, or another example from a real recent experience that I had, people having jury duty. But it's not just about capacity. The problems that we have with planning go beyond our capabilities and into the what? Not just whether or not we can finish what we've planned, but whether or not we're even going to execute on what we plan in the first place. If the plan was good. So this discussion is not just about rearranging the work or rearranging our estimation abilities so that you end up with the same planned product with a kind of a different execution style. But this discussion is about a more fundamental and foundational approach to planning. If we take in our planning exercise as a single moment in time task where we lay out our game plan for the next, let's say, eight months. We have a long project in front of us and we want to lay out our game plan for that long project. And we start to create a pathway where in the first month, we kind of lay the groundwork for what we're going to do in month two and then expand on whatever we do in month two in months three and four. And then we build variations on the things that we built in months three and four in months five and six. We polish things in month and month seven. And perhaps we do user testing in month eight. None of these things sound bad on their own. But what we've done unwittingly is we've built a path dependent model. In other words, our fifth step can only happen if our fourth step happened and the fourth step can only happen if our third step happened. And so if we diverge from that original path, let's say in our second month, we realize that the market doesn't really want the things that we're planning to do in month three. Well, now our entire pathway changes. And there's some work to be done in re-planning and responding to this change. Very often, a lot of the kind of built up preconceived ideas about what we're going to do with our resources are based on the first path. So this can be very expensive if you have a lot of path changes in a path dependent plan. It can also be very scary for people who are on a team, for example, who are constantly changing that path because they don't know if the path is getting ready to end or if it's going to go on twice as long as they had expected it to. Finally, it's important to note that the longer that pathway is, the less likely it is to happen. The longer the pathway is, the more opportunities there are to diverge from that pathway. Additionally, as time passes and as more is added to your already traveled path, the more your environment changes in ways that you can't really predict requiring a change in that pathway. Unfortunately, as humans, we often fall prey to things like sunk cost. So we choose a path and because we go 50% of the way down that path, if we find out that the path is leading towards inevitably a bad end point, we still feel like we bought in originally and we want the path to work. So we have a hard time abandoning that particular pathway. This path dependent model for planning may seem like a good idea because it helps us gain a feeling of certainty early on. We can project into the distant future and we can take what we currently think we want or need and imagine when we will have it. This satisfies a lot of our human needs, like the need for certainty, as well as the need for immediate gratification. The feeling that we are going to get the thing that we want right now, even though the timeline tells us that it's not going to be until much later. So how do we fix this problem and how can we plan in ways that don't expose us to all of the kind of risk that we've just discussed about a path dependent model? Well, let's imagine a scenario where a path dependent model is the only thing that could possibly work. A path dependent model might be the only thing that can work if you have a robot that can only execute tasks, a robot that cannot evaluate their environment and they don't have any way of taking additional cues in the future in no way of responding to their context. So a path dependent model in this case makes sense. Additionally, we often operate in path dependent models that we don't really have control over to begin with. However, if we are creating a plan, if we can avoid a path dependent model and instead look at other possible models, we might be able to avoid disaster and risk altogether. For example, imagine that instead of a robot, you have a decision-making agent, like a human. The human can evaluate the context that they can make an intelligent decision along the way. You can give a rough definition of where that human should go, but making a determination about, for example, a detour in a given context allows the human to respond to the environment. So when you create a model that provides for agency during the execution phase, you can intelligently respond to changing circumstances. So here's what I recommend. When you are in the planning phase, whether it's for a project, for your day, perhaps for your life, evaluate what those trade-offs are. Do you have an agency to be able to make decisions on the fly? Is there some hybrid between laying out a plan but then leaving room for flexibility? Ultimately, when you were planning software projects, one of the most valuable things you can do is make planning a function rather than a document. Think about this for a second. If you imagine that planning is a repeated function that produces a short-term list of actions. This requires that you have some level of agency to perform this function, rather than starting a project with a list of things to do that eventually degrades. It eventually is no longer as relevant because you're starting to learn more as you go through that project, instead you start a project with a planning session. This is a function that you and your team perform. If you're like most developers, you're probably hearing this and you're immediately correlating this to an agile process. The fundamental tenet here though is about thinking about the path dependencies. The longer you have on your path of dependencies, the more risk you're accepting. If you can create shorter pathways and instead rely on functions and agency in your planning process, you're more likely to be able to respond to the context, be able to respond to the environment, respond to changes rather than believing that your plans are going to mitigate all of your risk for you. Thank you so much for listening to today's episode of Developer Tea. Thank you again to Leno for sponsoring today's episode. Get $20 worth of Leno credit by heading over to Leno.com slash Developer Tea. Using the code Developer Tea 20, that's Developer Tea, and then the numbers 2020 at checkout. Today's episode, along with every other episode of the show, can be found at spec.fm, and today's episode was produced by Sarah Jackson. My name is Jonathan Cutrell, and until next time, enjoy your tea.