I've been in your seat before where you're sitting looking at a code base or you're looking at a process you're looking at a set of meetings maybe you're looking at a spreadsheet and this thought crosses your mind why on earth would anyone ever do it this way and then another thought crosses your mind maybe we should do away with it maybe we should fix it by deleting it maybe we should throw it out and start over new start over fresh new project we're going to rewrite the app we're going to come up with a new way of doing things and you might be successful you may have a good point you might need to rewrite the app but i want to give you one word of caution and it comes from an early 20th century author named gk chesterton the concept of the app is that it's a way of doing things that are not going to work and the concept comes from a parable written by chesterton it's called chesterton's fence i'm going to read it to you there exists in such a case a certain institution or law let us say for the sake of simplicity a fence or a gate erected across a road the more modern type of reformer goes gaily up to it and says i don't see the use of this let us clear it away to which the more intelligent type of reformer will do well toensionate the platform and the platform may not be the best platform for做 let us clear it away to which the more intelligent type of reformer will do well toensionate the platform and the platform may not be the best platform for做 answer, if you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it. If you're like me, you have had a PR review that went similar to this. A more senior engineer comes along and looks at your big refactor or the PR that you're taking out a bunch of unused code, so you think, a bunch of unnecessary tests. They come along and they say, why are you doing this? And you may naively respond by saying, well, I don't think we need this. I don't see why this is there. And hopefully, the more senior engineer will say, you need to do a little bit more digging. You need to understand what this is. The summed up version of this is, until you understand why something is there, don't take it away. Don't remove it. What is the basis for this? I'm going to give you kind of the basis for your original thought, right? The common concept here, the fallacy that we fall prey to comes from a bias, which we talked about on the show before, called illusory superiority. This is us overestimating our own abilities. You can also see this in the Dunning-Kruger effect, where we have a limited understanding, but we have the belief that our understanding is much better than it actually is. Most people will rate themselves, as better than average. And we apply this in many circumstances. In this particular way, we're actually applying it in kind of a passive way. We come along and we encounter something that someone else has done, and we apply some surface level judgment, some kind of call that we are making that implies a lack of confidence in our, our, our, our predecessor's competence. Okay. In other words, we don't think that the people who were doing this before were very good at it. And so on this basis, we imagine that a lot of what they did was done in error. And not only was it done in error, but it can be disposed of without much thought. This is a mistake. This is a mistake. Most people, do not act without a reason. Most people don't do extra work without a reason. Most code doesn't come into existence without a reason. And so if we were to actively reject the bias, actively reject the cognitive distortion, that informs us that we somehow have the, the market, we've cornered the market on, um, you know, good engineering, that we've cornered the market on whatever the domain is that we're working in, that we have all of the right processes and everyone before us was making grave errors, that everything they did followed suit. If we were to imagine that we are more like our predecessors, then we can adopt a curious mindset. Now, I want to make sure that I'm not going to go through all of this, but I want to make sure that you, uh, don't take away the wrong message that this is justification for leaving everything as is, right? What we're not saying is that you should never, uh, you know, rewrite the app or you should never rebuild that process or whatever it is that you're considering. Okay. Instead, this is a campaign against recklessness. Okay. Understand the things that we're criticizing, that we should try to imagine that they exist for a good reason. And someone did once believe that it was a good reason. If we can adopt this mindset first and whatever we do next will be informed by their reason. Think about it this way. You may still choose to make the, same decision, but now you may do so with more information about what you'll do afterwards. You're going to remove that test, but you're going to write a new one that, uh, does a better job than the previous one. You're going to remove that particular meeting on the calendar, but you're going to adjust the agenda for a different meeting to make sure that the same problems are solved. If we take a moment and try to imagine that we are more like our predecessors, we are more like each other than our heads, uh, our, our fast thinking processes, our intuition tells us, then we have a bigger opportunity to learn and build upon the learning of our predecessors. Thanks so much for listening to today's episode of Developer Tea. I hope you enjoyed this episode. If you did, please leave a comment and subscribe to our channel. And if you would like to see more of our future episodes, please visit our website at developertea.com. If you did, please leave a review. The best place to do that is in iTunes. This helps us stay in the running on the charts on iTunes to help other people find the show naturally, organically. Another great way to help other people find the show is to literally show it to them. If you think this episode was useful to you, or you had somebody pop into your mind while you were listening to this, you're like, oh, they would definitely appreciate this, or that person needs to hear this. Uh, go ahead and, uh, share this episode with them. It's the, uh, the best way to get somebody else to try, uh, try listening to this show for the first time is for you to share it. Finally, if you have not yet subscribed, that is the best way for you to not miss out on future value this show can deliver to you. Thanks so much for listening. And until next time, enjoy your tea.