> ...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.
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.