That’s an interesting way to put it. I think that might be a good rule of thumb to help future maintenance: Avoid unintentionally erecting Chesterton’s fences.
This is a great rule of thumb. I often find I unintentionally do that all the time and then I have to figure out why I did something I did. Trying to avoid that with good comments, documentation, etc. earlier in my career would have been a great practice.
I find I often think something is so common-sensical that I would never forget and then come back a while later and have completely forgotten.
The opposite of Chesterton's fence is "traffic cones" in my lexicon.
As in, "put some traffic cones around that hack" meaning make sure there is a comment or appropriate error message or something that will make it clear to posterity that this is a known temporary sketchy situation, not an accidentally load bearing wall"
See, this is the sort of behavior I would wish companies would test for when hiring engineers.
Another (in-house, salaried) contributor to the project I took over added a error message (in a very specific error handler for exactly one REST endpoint), and I quote
raise Exception("could not load data because of error")
FWIW I got this way thanks to a stint in the sysadmin/support/operations world at the start of my career. I wonder if trying to give juniors similar experiences might help jumpstart the process of getting this kind of intuition.
When you operate software, you realize all the little things a developer can do to make the operator's life much easier or harder. I always thought this was the "true meaning of DevOps" -- thinking of how to make it easy to operate the software at dev/design time, as if it were an old school shrinkwrapped application like Windows 95... but instead it got turned into writing terraform or something haha.
Well, funny thing is, that developer was also the operator.
Because if he's the only one that understands the error message, he's the only one that can fix the problem.
That's how you get credit with the suits if something breaks.
No one ever notices a stable application. A programmer fixing a problem that no one understands? That must be a very smart person indeed.
I'm being needlessly cynical at this point. This was just one person at one company. Overall, I do think that given the right incentives, what you describe can happen. But it does not someone in leadership to care. And that's a hard sell to me.
Sigh, this is cynical but I've seen that sort of thing too and it really bums you out. When you're in an environment where this kinda crap isn't well understood it becomes frustrating, you end up feeling like you're rewarded for mediocre software engineering and punished for thinking ahead.
This is a great rule of thumb. I often find I unintentionally do that all the time and then I have to figure out why I did something I did. Trying to avoid that with good comments, documentation, etc. earlier in my career would have been a great practice.
I find I often think something is so common-sensical that I would never forget and then come back a while later and have completely forgotten.