Where do you feel most limited? That's what we're talking about on today's short episode of Developer Tea. My name is Jonathan Cutrell. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. And one of the things that we talk about a lot on this show is cognitive distortions. These are filters or kind of lenses that you see the world through. And these have a major effect on your belief, structures, and they have a, of course, major effect on the way that you react to the stimulus that you receive in the world. Whatever that stimulus is. That's a fancy way of saying, however you make decisions is going to be largely affected by these distortions. And there's a lot that we've talked about on this show. And we've probably talked about this one quite a few times. But I want to talk specifically about how this particular distortion limits what you believe and also what you believe is possible. As engineers, we know that so much of what we might currently believe is distant or close to impossible, that engineering and science and that iterative method, you know, question and inquiry, all of these things have made so much that we once thought was impossible, possible. And that's kind of the muscle that I want you to stretch and inspect in this episode. Because this particular cognitive distortion is egregiously difficult sometimes to get passed. And the cognitive distortion is kind of a mix of two different things. One is binary thinking. We talked about this quite a few times on the show. You can also call this false dichotomy thinking. The idea that in any given scenario, there are only two options. There's almost always more than two options. There's almost always more than two answers. What's really interesting about this particular distortion is that it's easy to see why our brain does this. It's easy to see that it's much easier to think about two things than it is to think about three. It's easier to weigh the pros and cons between two options than it is to weigh them between three. And so if we are aware of this, we can see ourselves going to this very easily polarized way of thinking. Most obviously it happens in politics. There is one side or the other. But we also think this way in sports. There are very few large-scale sports that have more than one team playing at a given point in time. Most often those sports are single player. So we end up with this easy to understand or easy to comprehend the differences between these two options. So it makes it tempting to polarize your options so that you can either subscribe or deny. You can either get behind something or you can push away from something. It's much more nuanced in reality, right? Politics are obviously much more nuanced. And certainly all of the decisions that we make as engineers, if we end up in this kind of false dichotomy world where we pit one thing against another, those very often are much more nuanced as well. It's not one language versus another language. It's all of the options that are possibly on the table. And so our brain works very quickly to reduce that variability and to try to make the decision easy, to try to make the comparison easy. This is purely for efficiency sake. Our brain is kind of interested, biologically speaking, in doing the least work possible, conserving the most energy for other tasks. And so it's easy to see why a false dichotomy could rise up in that scenario, right? Your brain is pushing you to create very distinct and obvious categories. Similarly, this is the second cognitive distortion. And when these two combine, they can create kind of a dangerous scenario. The second cognitive distortion is thinking zero sum. So what does that mean? We've probably heard of zero sum, the concept of zero sum. The basic idea is that whatever resources are currently available, and we'll get into that a little bit, whatever resources are currently available, that's all that will be available. So we have to allocate those resources in some particular way. And most critically, if you take resources from one location and you put them into another location, you are kind of unequivocally taking away from one thing to give to another. This is zero sum. And there are systems where this is the case. For example, conservation of energy is zero sum. There's only so much energy in the universe. And specifically, you can kind of observe this with small physics problems. And as far as Newtonian physics are concerned, which is a little bit more detailed than we really care about for this thinking model, energy is a zero sum game. But most are the things that we encounter. Most other things are not zero sum. And this is how it works with that kind of binary false dichotomy, the binary thinking. If you have resources, you can either give them to one or you can take them away from that one. Right? You can either put your resources towards this direction or towards that direction. And it's easy to think this way. It's easy to believe that because the dichotomy is so clear that putting your resources towards one effort is necessarily starving another effort. And we're kind of taught this with our opportunity cost models. So this is what ends up happening. And this is why it's so detrimental to software engineers. If you take time away, let's say from developing features and you put it into testing. All right? Hopefully you can see where this is going. If you take time away from pushing the product forward and you put that time into something else, then you are sacrificing your product development. Right? Instead, you've taken those the time, that input that you otherwise would be pushing the product forward and you're putting it into something that is not pushing the product forward. Now, the assumption here is that you only have so many resources. That's the first assumption. The second assumption is the idea that once you allocate it, that that's all the effect that there will ever be of that allocation. We know this is obviously not true. If we spend time allocating time towards testing, right? If we spend that resource towards testing, generally speaking, right? We're going to get extremely detailed. But generally speaking, that's going to pay you back in the long run. It's going to move your product development efforts forward as well. In this way, our testing efforts are not a zero sum. When we take time away from one thing and put it towards another, it doesn't mean that we are starving the other thing. This is very difficult for us to quantify. It's difficult to totally understand all the implications of this. It takes time to actually analyze this stuff. It's possible, actually, it's almost certain that at some point, more time into testing is taking away from the product development. Right? That makes sense. At some point, you're going to reach a threshold where testing anymore is not adding value. It's not furthering your product development capabilities anymore. Then in fact, it's probably not a good idea to push any further on, let's say backfilling your testing. Now, here's the unfortunate truth. I'm not going to be able to give you all the tools that you're going to ever need to be able to analyze those situations. But the important tool that I want you to take away from this episode is to always break through that false dichotomy. Always look for that third option. Always ask, is it actually a zero-sum game? Are we just assuming that it's a zero-sum game? Can we possibly get two things for the price of one? This is something that, again, is drilled into our heads that there's no free lunch, that there's no way that we can get one thing without sacrificing another. This is very, very unlikely to be true in most scenarios. Some very stable data suggests, as an example, that increasing your delivery speed will also, this is not intuitive. Increasing how quickly you deliver your code. In other words, how often are you deploying your code into some kind of production environment? If you have a higher deployment rate, and you can ask yourself this question, what your intuition says, are you more likely or less likely to have a high failure rate? Our immediate gut intuition would say, oh, with all that change, with all that turmoil, you're more likely to have a high failure rate if you're shipping code very often. But as it turns out, the data doesn't support that conclusion. This is a type of zero sum thinking. You can either have rapid deployments, rapid development, or you can have stability. As it turns out, that's not true. Those things kind of go hand in hand. As always, I want to encourage you to keep on asking and interrogating all of those assumptions, all of those gut intuitions that you make about your decisions. Thank you so much for listening to today's episode of Developer Tea. If you enjoyed this episode, please share it with someone else who you think might enjoy it as well. With everything that's going on in the world, there's so much turmoil with a global pandemic and wildfires out in California, and the devastating weather that is hitting the gulf. I want to give you a final note of encouragement and remind you that it's okay sometimes to slow down and just take care of what you need to take care of. Thanks so much for listening to this episode. This episode is produced by Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.