Chesterton's Fence: A Lesson in Second Order Thinking

I manage a highly complex AI service, and from time to time make config changes, and part of that duty is config cleanup -- removal and simplification. This is a necessary job in the past I have found copy-pasta where settings overrides for one environment are incorrectly copied to a similar one, leading to bad customer experience. As a personal policy, before submitting the cleanup PR, I go back in git history to when the config was introduced to understand…

I'd argue that incremental change strikes the balance between tearing something down and being paralysed by potential consequences. Also, you can only learn so much by passive observation. Eventually you have to apply a small stimulus (incremental change) and observe the response. If the response is bad reverse the increment. Caveat is that if you reach a local maxima a more drastic change may be required, but the journey to the local maxima has probably taught you enough about the…

Rust is not mentioned in the article. From HN's guidelines: > Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.

> Chesterton went on to explain why this principle holds true, writing that fences don’t grow out of the ground, nor do people build them in their sleep or during a fit of madness. Chesterton never had to maintain an old code base. People do "build fences" during a fit of madness, or maybe during a bout of incompetence. But even then his point is well taken, because it's hard to tell if a given fence was built by a…