There's a fun part of starting every new software engineering job as you navigate an unfamiliar codebase:
You want to make some changes, maybe refactor some old code, and you see some things that strike you as odd.
You ask yourself, "Was it done this way for a specific reason, and I'm just missing something that I don't understand yet? Or was this just always broken or not well thought out to begin with?"
You scour the codebase for any READMEs, look at past pull requests and commit messages, and hunt for any wikis you can find. It wasn't documented.
You ask the engineers who you think might have some context, but they're not sure why it was written that way either.
You ask Claude for more info, but it feels like it's grasping at straws as well, and you're not quite sure how trustworthy any answers you get are at this point.
So you make your changes, test as best you can, merge the pull request, and hope that nothing blows up.
Best-case scenario: Everything's fine. Worst-case scenario: That was a load-bearing console log you just removed, and you've taken down production.
There is a parable by G. K. Chesterton, an English philosopher and theologian. It goes like this:
In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or 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.
Applied to most scenarios, the lesson is that you need to understand why the thing was there in the first place before you get rid of it.
Recurring meeting you don't like? Figure out why the meeting was created to begin with. If it's no longer serving its stated purpose, great, remove it.
Process you don't agree with? Understand why the process was originally instituted. Maybe it was to solve an organizational problem or to clarify something people were frequently confused about.
Code you don't understand? Maybe there were technological constraints or business requirements influencing the decisions made.
The point is: before you go about changing things, make sure you understand the historical context and any nuance that may not be immediately obvious to you at first glance.
As a software engineer refactoring code, be aware of Chesterton's fence. Do your due diligence to understand why the code was written the way it was.
And as code authors, make sure you leave the breadcrumbs behind for your future coworkers, maybe even for your future selves. Make sure to explain the purpose of the fence when you build it. In the present moment, you have more context than anyone else will ever have.
Create that README file. Write the Notion doc. Include context in your pull request descriptions (explain why, not just what — bonus points for including screenshots or videos!). Write tests to verify behavior and prevent regressions. Use public Slack channels rather than DMs.
Your future self will thank you. Because there's nothing more frustrating than trying to figure out if Chesterton's fence was ever even working to begin with.