Chesterton's Fence

You're new to the codebase. You open a file and spot something that looks wrong. A weird workaround. An inefficient algorithm. Code that seems obviously broken.

Your hand moves toward the delete key.

Stop.

There's a principle for this moment: never remove a fence until you know why it was put up. Someone built that fence. Expended effort. Made a decision. That "ugly" code might be handling an edge case you haven't encountered yet — a browser quirk, a race condition in a legacy integration, a performance issue that only shows up at scale.

Delete it without understanding and you're not cleaning up technical debt. You're removing a fix for a bug you haven't met yet. That bug returns. Usually in production. Usually at 2 AM.

So before your hand hits the delete key, do the work. Check the Git history for the commit that introduced it — a good commit message will tell you what it was solving. Look for a linked issue or ticket. Find the original author if you can. What you're looking for is the problem the code was written to solve, not just what the code does.

If you still can't find a reason, don't tear it down. Leave it alone and keep learning the system. The fence might still need to come down eventually — but understanding why it went up tells you exactly when it's safe to remove it.