I've been in your seat before where you're sitting looking at a codebase or you're 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, 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.
It comes from an early 20th century author named G.
K. Chesterton. 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 to 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?
You may naively respond by saying, well, I don't think we need this.
I don't see why this is there.
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 gonna give you kinda 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 predecessors 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 an 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 market, we've cornered the market on you know, good engineering.
Yeah, we 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 you don't take away the wrong message that this is justification for leaving everything as is.
Right? What we're saying is that you should never, 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.
That we should 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, then 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 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, 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 T.
I hope you enjoyed this episode, if you did, please leave a review.
Best place to do that as an 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.
Go ahead and share this episode with them.
It's the the best way to get somebody else to try 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
