Chesterton's Fence
Be careful how you approach things you feel have simple answers
There are many ways to consider what’s happening inside Twitter’s company right now, and most of them are bad. Second-order thinking is one way, and it’s a lesson we should all absorb.
This all started with Musk’s ego-maniacal belief that he knew what could be best for Twitter. Regardless of his lack of experience in the social media space, he felt that his pseudo-engineering background makes him qualified to jump in and save the company.
The mistake he’s making is a pretty common one, which makes you realize how fallible we all are if it’s possible for even him, so-called genius, to make this error. There is a well-regarded heuristic named “Chesterton’s Fence” that describes this type of thinking. Simply put: You feel you know how to solve a problem and do not consider how the problem arose, and what attempts in the past occurred to resolve it.
In software development, this type of thinking is rampant. At micro levels, we all look at code and think, “I’d refactor this because…” and the reasons are anything from syntax, to choice of language, and millions of insignificant reasons in between. At macro levels, we all have experienced the toil of existing systems and suffer through it with the attitude of resentment. We boil with anger at the original authors for building something so brittle. The mistake here is believing that there is no good reason for the system or code being in the condition it is. We make premature judgements that the problem exists only because no suitable solutions were provided before.
The lesson here is that first-order thinking is usually wrong, and that code exists, in fact, for many good reasons. Here is a quick list of scenarios in which today’s “bad” systems exist:
The system was created in a time before many newer solutions existed
The system truly worked before and the environment changed to make it no longer work
The style of “Worse is better” was applied to the problem in the past, and now the minimum viable product is failing expectations
Many of us could say we’ve experienced some these conditions, if not all. It’s everywhere. And here lays the lesson, waiting for us to pick it up — and yet many of us don’t.
Before jumping to conclusions, take the time to fully understand the existing system. Absorb as many historical contexts as can be found, and deeply respect the previous owners of the system for their attempts to do good work, to the best of their abilities, based on the existing tools they had.
Be sure you calculate all of your assumptions against the reality of the existing system. Never apply a solution to a problem based solely on your imagined context. You are guaranteed to have missed something.
Respect your forebears. Remove your own ego, put aside your own experiences with systems and code from other places and different contexts. None of your previous experience can be applied verbatim, they all require a context shift, and implicitly that will change the outcomes.
Be a gracious student of the history of the current system, so that you can be a responsible steward for the future.