Today we're going to take the opportunity to do a thought experiment. It is the weekend after all. We can think about things that don't exist in reality and that can be instructive. So I want to set up the thought experiment with a very simple question followed by some rules that govern the thought experiment. And once you have the thought experiment laid out, I encourage you to pause and think about it for a little bit. Think about the merits of the directions or the choice that I'm providing to you and then play the rest and compare your notes to mine. The thought experiment is very simple. Let's imagine that you want, to accomplish some big goal. And for most of us, that's making our stakeholders happy, building a product that disrupts a market or perhaps captures a big chunk of the market that we have yet to capture, or maybe just a feature that increases retention. Maybe we just want to build something that is valuable to the organization, whatever it is. Imagine one, significant goal. And the question is simple. The question of this thought experiment, the core pathway, fork in the road that you have to choose a direction around. That question is, should you take one major step that you plan out as thoroughly as you possibly can? Or should you take a series of completely random steps? To get to your goal. Think about it for a second. And I'll restate this. Should you take one major bet? Should you make one major investment? One big step that you plan out thoroughly? You think about it in its entirety. You try to do your best in making that step a good step. Or should you start from a position that you're not good at? And take small, random steps. Now, here are the constraints, the important parts to consider when you're thinking through this thought experiment. First, there is a significant amount of complexity or uncertainty in the system you are working on. Okay, this is an important rule because it is almost always true. It's almost always true in the major work that we do as software engineers. Usually, there's significant complexity and uncertainty, whether that is market uncertainty, maybe it's product or technical uncertainty. It could be behavioral uncertainty. There's complexity as you begin to solve more and more valuable problems. Typically, the complexity goes up. So, for this to be a reasonable thought experiment, where we're actually exploring something valuable to you, we want to hold those, those things true. Right? So, we're holding true that there is significant complexity and or uncertainty in the system that you're working in. The second thing that we want to hold true, the second thing that we want to hold true is that after any given step, you can evaluate, you can review what happened in that step. You could test that step against, whatever that delivery metric or value metric is. So, you're allowed to review it. You don't have to, for example, in the random case, you don't necessarily have to just continue on randomly. This is not a question of should we do a truly fully random walk? Because as it turns out, that's not a very instructive exercise. But after any given step, whether that's a big or a small step, you can review it. You can review it. You can review and adjust. So, hopefully, you're quickly getting a picture of this. A random step. Let's imagine that your target is in a vector direction. Okay? So, wherever you are now, you're trying to get to a place that is some vector away. That means a distance and a direction. And we're using this as kind of an abstract model because it's, it's instructive. You can imagine that this is a multidimensional space, right? That you're trying to get to a point in that multidimensional space through a series of decisions. But you don't know where that point is. Let's imagine if it is on a 2D plane. It is randomly chosen. Now, your first plan, if you were to try to gain some information about where that point is, you may get some vague information. But you won't get true information until after your first step. Hopefully, this is starting to shape up for you. And you can kind of see where the thought experiment is leading. If you were to take one large step in a given direction, right? The worst possible outcome would be if you took a step knowingly against the vector. Think about it like this. If you are standing, uh, in the center of that plane, and you know, uh, that your, that your target is, you know, if we're going to use cardinal directions directly to the east of you by a hundred paces. If you were to knowingly take a, a step to the west, then you're going directly away from your target. So this is the worst possible decision, which means necessarily, necessarily that a random step, is better. And if we continue with cardinal, uh, direction, and if we were to slice that up into 360 degrees, uh, then there are 359 choices that are better than directly west, or perhaps a, uh, more accurate way of saying it is there. There are about 179 choices that are less bad than directly west. So what this means is, unless we are knowingly going away from our target, a random decision is not always necessarily a bad decision. So let's extend the thought experiment to the random versus a single step decision making the large step versus a series of smaller random steps. Let's imagine that even with the smallest amount of research or insight, uh, we can direct the random steps to be incrementally less random. In other words, after the first step that we take, because we can review our work, we could revise our direction. So we could, for example, take a subsequent step that is less random. For example, we may go from 360 degrees of options to 180 degrees of options. So, we could go from 360 degrees of options to 180 degrees of options. And this is the important insight, the important insight to gather from this thought experiment. If you are planning to take a large step, it is important to recognize the cost, the cost of learning before taking action versus the cost of learning after taking action. You may have accepted the idea that learning is a process, but you may not have accepted the idea that learning is a process. So, you may have expected that we would choose one or the other on this podcast. And most of the time, you're right. Most of the time we would choose to go with these small steps, even if the first one is in a random direction. And this is mostly because as a general rule in software, learning after the fact is less expensive than learning before learning by observing, learning by doing something. Learning by testing something in real life is typically better than trying to predict. We're better at observing than we are at prediction. But it makes sense for you to weigh these options. The cost of learning beforehand versus the cost of learning after. And it's not always the case. This is the important thing to understand. It's not always true that learning through those small steps, through those small steps, through those small steps, through those small steps is better. It's not always true. For example, imagine that you're performing surgery. You wouldn't want to have a surgeon that is learning through small steps where they're making mistakes and trying to correct those because the expense of correcting, the expense of adjusting, the expense of learning in that environment is much higher, much higher than the expense of learning beforehand. So the critical question really is how do you choose what to do? How do you choose which direction you're going to step? How do you avoid going directly in opposition to your goals? The most critical concept, here is how are you planning to learn? It is almost impossible to take a single step and arrive at your location randomly. Arrive at your destination, your intended plan. To arrive at that spot is very unlikely in complex systems. And so the process of arriving or changing your location, changing a complex system, that process requires learning. Learning is how you will decide where to go. This is so important to grapple with. Learning is how you decide where to go. A lot of people approach a given project, approach a given feature that they're building, whatever, even their careers, they approach their planning, with the assumption that they already know what they need to know to succeed. And all it is is execution. The only thing they have to do is write the code. The only thing they have to do is travel the path, travel the career path. And as long as they continue on knowing what they already know, that they'll arrive where they need to go. That it's just, at that point, a logistics problem. And this... This is a critical misstep. If you don't optimize for learning, and, critically, the cost of learning, then you'll find yourself way out to the west, accidentally, in your complex system. Thanks so much for listening to today's episode of Developer Tea. I hope you can see how this thought experiment applies to your work, to your daily decisions, to your career decisions. If you enjoyed this discussion, you almost certainly would enjoy being a part of the Developer Tea Discord community. Head over to developertea.com slash discord to join today. Thanks so much for listening to this episode. If you enjoyed it, please leave us a review in iTunes or whatever podcasting platform you use that has review functionality. Some of them don't. Some of them do. If you leave us a review, I will absolutely see it. I will absolutely read it. And that feedback means a lot to me. If you want to influence, one of the best ways to do that is through leaving a review. It's not just for me. It's for your fellow engineers, for the industry, for the product owners, for the executives that listen to the show, for anybody who comes along who tries to decide whether or not they're going to listen to Developer Tea. They're going to probably read your words before they listen to mine. So that is so critical for the health and longevity of the show. Thank you so much for listening. Thank you so much for engaging. And until next time, enjoy your tea. Thank you.