Every action we take, especially our conscious actions, and sometimes even our unconscious actions are in a way backed by some kind of hypothesis, some kind of reasoning. We choose to do something because of something. In today's episode, we're going to talk about this reasoning and what happens when the reasoning is done automatically for us. My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. We've talked about implicit and explicit many times on this show before. Part of the reason for this is because implicit, very often, is something that has lodged itself into our behaviors and into our brains. The implicit things that we do are the things that we're not really thinking about. We're not articulating. The explicit things that we do are the things that we've taken the time to articulate. So if every action that we take is backed by some kind of hypothesis, what happens when we're not even sure what that hypothesis is? This implicit hypothesis ends up being our reasoning without us really even knowing it. What can happen when we're operating on an implicit hypothesis? Well, first of all, we need to kind of explore where an implicit hypothesis might come from in the first place. Certainly, we are acting in random ways, or at least we're not attempting to act in random ways. We have some kind of reasoning, but we're not always thinking about the reasoning in the context of now. What does that mean? Well, a lot of our reasoning is, as far as we're concerned, ancient. It's true to us at a very deep and core level. This is because our implicit hypotheses, they come from somewhere, where do they come from? They come from our beliefs. Our implicit hypotheses come from our beliefs. And if our beliefs are informing our implicit hypotheses, then our beliefs, whatever structures our beliefs, which is usually our experiences, our experiences are informing those beliefs. So just across that kind of chain, our experiences from the past form our implicit hypotheses for the present, our experiences from the past through the forming of our lasting beliefs, influence and ultimately form our implicit hypotheses about the present. Okay, that's a lot to take in, so I want to make it kind of tangible with an example. We're going to actually talk about a couple of examples right after we talk about today's sponsor, Elastic. Elastic enables the world's leading organizations to put their data to work using the power of search, whether it's connecting people and teams with content that matters, keeping applications and infrastructure online or protecting entire digital ecosystems. Elastic search platform is able to surface relevant results with speed and at scale. Learn how you can get started with Elastic's search platform for free at elastic.co forward slash FAO that's elastic dot CO forward slash FAO. There's so much to elastic for their support of Developer Tea. I want to paint a picture of a scenario where implicit hypotheses ultimately could lead you to make bad decisions. After we do this, by the way, we're going to talk about why implicit hypotheses are not always bad. But first, let's talk about a scenario where they are. Let's imagine you're on a team and your team has been working in startup mode. This really means that you're trying to ship features as fast as you can without breaking everything that you touch. This might mean that you write as many tests as possible, but maybe you're not covering everything that you know you should. And as a result, you're also making a few shortcuts here and there and building up sudden tech debt. And tech debt is no stranger to any of us. But you've recognized that there is one area that seems to be producing a lot more bugs than you're comfortable with. And so you bring this up at a team meeting with you and the other engineers and engineering manager, maybe a product manager is there with you. And you say that you'd like to pay this technical debt as soon as possible. A product manager talks to you and the other engineers about what it would take. You estimate to some decree of accuracy, but ultimately the product manager says, well, I don't think that we can do this now. We're willing to continue experiencing these bugs, but we need to get these other features shipped. This is a classic problem because how can you really perfectly prioritize in a situation like this? It's very hard to do. Now, let's imagine that you choose to work on this technical debt outside of the scope of your normal work. In other words, you say, OK, well, I'm going to keep doing this other work, my kind of main work, but I'm also going to work on the technical debt. This moment is where you've used an implicit hypothesis. There could be multiple implicit hypotheses. In fact, there almost always are multiple hypotheses in a given scenario. You can even have a mix of explicit and implicit hypotheses. In this scenario, you hypothesize implicitly that doing this work outside of the course of your normal work is going to result in a better scenario, better outcome in the future. Hypothesis may be informed by some previous experience of having not paid down technical debt. Now that you've learned this lesson in your mind, you think it's unacceptable to forge ahead without paying this down. Therefore, you're willing to sacrifice. Maybe you're going to sacrifice your personal time or maybe you're going to work a little bit faster on the other work. The problem that arises hopefully becomes clear. In fact, there's multiple problems that could arise as a result of this. The first one is if you're working on this alone, then a lot of the context that you otherwise would have if you had other engineers working with you on it is lost. You may end up paying down this technical debt, but the other engineers might continue to accrue the same kind of technical debt because you haven't had a chance to bring that work into the primary mainstream of work and therefore the other engineers don't really know how you've changed the patterns, for example. Other problems that might arise from this are really clear. You could get burned out very easily if you're working long hours. Or if you're having to take shortcuts on the primary work that is in that mainstream, the shortcuts are probably resulting in new bugs or new technical debt. I like this example because there is something good about your implicit hypothesis. What is the intuition that this growing source of bugs may ultimately lead your team to be disrupted in a more serious way, and that your ability to deliver new features may be impeded, and ultimately you need to prioritize this technical debt. That's a good intuition most likely. But the problem is that your implicit hypothesis of working on it anyway or choosing to do this outside of the normal flow, that part of the hypothesis is the misstep. Instead you can use that same intuition to share an explicit hypothesis. Your implicit hypothesis is technical debt is bad, especially when it's producing bugs. And we need to pay attention to it as soon as possible. This is a belief, an underlying belief, a good belief. But the bad belief that you would carry it around is that you can take care of it or that you have the capacity or the team is able to take on the extra work while you go and fix these technical issues. So if you dispose of that bad belief or maybe you don't know that the belief is bad, if you make it explicit, and especially if you have a chance to explain this to your team, now you can actually negotiate with the other members of the team. You can also have a chance to recognize which parts of your hypothesis are likely to be bad or which underlying beliefs you need to discard or create an explicit hypothesis that goes against that intuition that kind of says that belief is something that I need to ignore or that I need to hypothesize against. I need to do something that disagrees with my own belief. And this is why it takes explicit thinking. It takes slow thinking because you're going against something that is likely ingrained and deeply seated. So taking a chance to say, okay, we believe this, this tech debt is bad. We want to pay it down, but we know that we can't do this in parallel to all of the other work that we've committed to. Can we find ways to put this tech debt into a prioritized position every cycle. Maybe we spend a certain amount of time. And this is the back and forth. We're not going to get into the specifics of how you solve that problem because every team is different and your schedules are different. There are a lot of ways to solve this kind of problem, but making the explicit hypothesis and working through those with your team is going to result in a much better outcome. It's going to result in a much better outcome because you're avoiding those bad intuitions. You can think about your beliefs as cookie cutter molds that you use over and over again in the future. You're underlying long held beliefs to your mind, ancient. And what your mind sees as long held beliefs, it will double down on. And so we use these as a template for our future situations. We use our existing beliefs as a template or a pattern to develop our hypotheses into the future. And this explains why sometimes these implicit hypotheses are good. They keep us from having to always rebuild all of our reasoning from the ground up. There's a lot of beliefs that we have that are valid. And especially this is true for things that don't have a lot of gravity that don't really matter which direction you go. So it is important to develop a keen sense of when the ramifications of your particular decision around to given hypothesis, when those ramifications are large. And when they are large, you very rarely are going to go wrong by developing an explicit hypothesis. Another time when determining an explicit hypothesis is useful is during a post-mortem exercise. I mean, you're looking back. You may take the time, especially in a failure mode, may take the time to say, what belief or what hypothesis that was implicit. Can I uncover that and make it explicit? So you are kind of coming to terms with your own hypotheses in that moment. Thank you so much for listening to today's episode of Development. I hope this is a useful way of thinking about why you choose to do certain things. You're kind of rational the way you develop your hypotheses around especially important decisions. Thank you to today's sponsor Elastic to get started with Elastic's search platform head over to elastic.co slash F-A-O. You can get started for free. That's elastic.co forward slash F-A-O. Thanks so much for listening to today's episode of Developer Tea. And until next time, enjoy your tea.