Chesteron’s Fence: Do not remove a fence until you know why it was put up in the first place

creating and destroying; built flying cars & autonomous vehicles, now building /faust, more here: /july, web: july.rocks

this is a great analogy for coding, many such cases on codebases where code seems to do nothing but might be there for a reason

dev (not french) @ le /bleu @elefant. 


lebleuelefant.com

The first thing a new hire does often is wants to do is rewrite a whole thing. It’s because they don’t know what the fence supports yet

I will argue though- if you think it through, and can think of a better fence, sometimes *it is* worth it to build that fence in a new way. Just because there’s a gotcha doesn’t mean it’s not worth rebuilding

yep, it just requires understanding of the original problem constraints that where in place when the fence was first built, and how a new context/time/your skill set/creativity could re-do that in a much better way.

but as a new hire is also hard to get buy-in from the bigger execs, even if you're really good at communication CTO's are biased to think they know better than the new dude in a month technical test or whatever.

i hate politics on workplace ngl. Code is pure. Humans make it messy.