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 why it was done the way it was, in case I am missing something. I call this "paying the Chesterton Tax."
Usually its fine, though once in a while the original author gets annoyed at second guessing their work long after it was considered settled. One recent curious example was when I found a specific setting was applied for one out of a set of many similar subservices; when asking around for why only one of them got it when the current data suggested all subservices would benefit, a senior "architect" got annoyed with me asking questions. As best I can tell: the project was shelved after a few months when the architect solved the primary issue and got bored with it / delegated the polishing touches to a junior engineer who went on maternity leave shortly after. Which is a fine enough explanation for me to proceed, but nobody's eager to admit such social causes.
> ...I go back in git history to when the config was introduced to understand why it was done the way it was, in case I am missing something. I call this "paying the Chesterton Tax.
Maintaining code I wrote 15-20 years ago I find myself doing this with my own commits. I have to get back into the mental place I was when I wrote the original code and then it usually becomes clear if it was an expedient hack or a thought-out solution for a corner case.
The worst feeling is "cleaning up" some code, discovering the edge case under which the "simple" case fails, then re-implementing the same solution.
Whenever I am in that expedient hack mode I've started commenting to explain my dilemma. My most valuable comments typically come out at that time.
Such and such can't be done right now because of such and such.
Often it doesn't matter if I ever resolve those comments or solve that problem I hacked through. The value comes from avoiding the rabbit hole next time.
If there were one lesson I could forcibly transfer into juniors via some kind of mind control it would be the lesson of reading my own code from 20 years ago and wondering what idiot wrote that and why didn't they explain XYZ better in the docs.
This is a good reminder to add code comments explaining why code is written a particular way. Also helpful is including breadcrumbs in comments and commits to relevant bug reports, docs, or commits.
You are external to the AI service, if you break the AI service you are still around to fix it. The consequences are relatively minor and easily remedied. Chesterton fence is about maintaining society, if you break that you may not be around to fix it so it stays broken, the consequence is major and not easily remedied. To force a software analogy; it would be like working on your autopilot software while you're flying on the same autopilot software - you're going to want to be very very careful when making changes.
As a senior engineer, I struggle sometimes with people critiquing my work. For me, it all comes down to pride and ego. It’s been especially hard the last year, as I’ve been vying for a promotion. I need to work on humbly and joyfully accepting feedback from others.
Usually its fine, though once in a while the original author gets annoyed at second guessing their work long after it was considered settled. One recent curious example was when I found a specific setting was applied for one out of a set of many similar subservices; when asking around for why only one of them got it when the current data suggested all subservices would benefit, a senior "architect" got annoyed with me asking questions. As best I can tell: the project was shelved after a few months when the architect solved the primary issue and got bored with it / delegated the polishing touches to a junior engineer who went on maternity leave shortly after. Which is a fine enough explanation for me to proceed, but nobody's eager to admit such social causes.