Sometimes our intuition, our guts, what our emotions are telling us, they can trick us. And if you've listened to this podcast, you're probably on guard to that. But even when we try to make a reasoned argument with evidence, there are subtle errors that we can make that cause us to call back on that intuition. We're going to talk about this collision 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. If I were to ask you, how long will it take you to do this particular task? I know we use estimation on the show quite a lot, but this is such a good kind of grounds for talking about confidence and the way that we make decisions or the way that we size something up. Estimation is a good grounds for that. And so is hiring. So is making any kind of architectural decision in our code. We're going to stick with estimation for a moment. And imagine that I'm telling you to provide some kind of estimate for some series of work. And your goal is to provide something that is relatively accurate. And let's imagine that there's actually good reason to do so. Right? So there's no slipping out from under doing this estimation. There are a few common tactics that we use as engineers to try to estimate. We're not going to go through them in detail, but let's talk about one of them in particular. We look at a story and we try to find something that is similarly sized. We try to compare what our current story is versus that other story. And when we find some reasonable comparison, we reflect on how long that other thing took. And by the way, we're using agile story, you know, user story language here. Like stories are essentially tasks if you're unfamiliar with the language. And you take this task, you compare it, you try to find similarities between this task and another task. And then you assign some number based on that other number based on the task that you found that was pattern matched to this one. This seems like an ingenious solution, doesn't it? When we look at one task and we say this task has a lot of similarities to this other task, we're using some pretty smart heuristics to do this. And let me be clear that this is probably not a bad idea. We look at the task and we say, okay, this feels like this other one. And you can already see, by the way, how our intuition and our gut is already playing into this a little bit. But hopefully you're saying to yourself, well, we are using information. We're using data about this other task that we've done. And we're using some kind of qualitative matching process, it's very difficult to explain exactly what that matching process is. But we're using some qualitative information to try to match those things together. And as it turns out, this is a really good plan because we're better at matching qualitative information as humans than we are at estimating quantitative information in a vacuum. In other words, we can compare things very well. In fact, we can even compare quantities very well. But if we're trying to come up with a quantity out of nothing, if we're looking at some kind of qualitative information and establishing quantitative information with no comparison, no base rate, nothing else to pull from, we're pretty bad at that. But we've done something kind of sneaky here. We've skipped over the entire process of estimating this particular story. How is that possible? We're going to talk about that right after we talk about today's sponsor. Developer Tea is supported by Square. There are millions of sellers across the globe using Square to run every aspect of their business, many are looking for customized solutions that are deeply connected and easy to use. This is where developers you come in. You can grow your business by extending or integrating with Square using free APIs and SDKs to build tools for sellers. Learn more by going to developertea.com slash square. Let's developertea.com slash square. This again, 2 square for sponsoring today's episode of Developer Tea. When we use this process of comparison, of one story compared to another, what we're actually doing is we're bypassing this estimation altogether. The information that we're actually answering is what is this story most like? What is this task most like? In terms of the rest of the work that I've done, what is this task the most similar to on that list? This matching process that we do is once again something that we're very good at as humans. But we often immediately fail to recognize that the estimate that we are providing is not based on any content of the task itself. It is an abstraction based on some kind of retrospective measurement. What does that mean? Well, it means that we're basically looking back in time and saying this other thing that we did, we're going to size the new thing that we're going to do based on this other thing that we did. Now, there's a lot of information loss when we attempt to do this. The first thing that's lost is what are some of the exceptions that we ran into with that particular task that we did before? Then more specifically, exceptions that we wouldn't necessarily expect in this new task. Perhaps a better way of thinking about this is to look at multiple tasks, they're in some kind of same category. What this would do is it would provide a base rate, evening out some of the maxes or the minns that you would otherwise experience because of outlying effects. Some of these factors are simply human factors. Sometimes we're more in the mood to code. We're experiencing flow state. We might have some higher level of productivity. This is especially true when we're talking about tasks that are on the lower end of the scale of effort. In other words, tasks that might take two hours versus tasks that might take eight hours. These are far easier to fall in that same category than something that takes three months versus eight months. Now, here's the critical thing that I don't want you to miss in all of this discussion about how we're not actually estimating. This is probably a very effective strategy. We've already mentioned that, but I want to double down on this idea. When we can find ways that we can use the things that we're good at as humans, rather than saying, oh, we're not really good at estimating. We shouldn't estimate it all. Rather than saying, well, our intuition leads us down bad pathways. Let's try to program it out of our processes. Let's try to remove intuition altogether. These are probably not good decisions to make because then we're losing out on something that we're actually really good at. In this case, pattern matching. Ultimately, our goal as an engineer, our goal as an engineering manager, as a product leader, wherever you are in your organization or in your career, our goal shouldn't be to create a singular dogma. But instead, looks at the various skills that we have and composes them together rather than trying to shoehorn a skill that we have into the wrong spot. Thanks so much for listening to today's episode of Developer Tea.I. Hope that this concept is opening up your mind about not just how estimation works, but some of the ways that we might be able to take advantage of the parts of our human nature, our human capacity, rather than trying to build systems that limit that human side. Thanks so much for listening to this episode. Thank you again to today's sponsor Square to get started with Square's APIs and various SDKs. Head over to developertea.com slash square today. We plug it every time and I'm going to continue plugging it because I just love how the community is growing and it's growing. One developer at a time. I'd love for you to join the Developer Tea.I. Squirtheadovert.tv developertea.com slash discord. You can join totally for free. Share your thoughts on today's episode or any other episode that you've listened to in the nearly 1,050 episodes that we've done of this show. You can talk about any of those subjects and more, really anything you're going through in your career in the Developer Tea.I. That's developertea.com slash discord. Thanks so much for listening and until next time, enjoy your tea.