The feat is impressive, but there is such a self-deprecating sense to this article that makes me sick.<p>Let me see if I get this straight:
"While on vacation, I spent a significant amount of my time with a node in our production cluster attempting to understand this problem"<p>"Eventually, I discovered a race condition that allowed an SO_WRITE interest to be set on a socket but never cleared."<p>"Upon returning to the office and offering up one heck of a mea culpa"<p>---<p>Took his own time to hunt down an extremely difficult to find bug and then fixed it. Yea, mea culpa all around. This is the kind of ridiculous attitude that has people working themselves to death.<p>I agree with the rest of the article, I think you should never be afraid to change and refactor your own code. This particular part of the article struck a nerve for me.
If you are afraid that you don't know what your code is doing, that's reason enough right there to spent some time working on it. You should never get into that situation.
Did this yesterday ... then I realized why more people (including myself) just don't bother.<p>I started on what should have taken 1 hour of work to do at 6pm... 7 hours later, I was almost done ... It threw off my entire schedule and destroyed my plans for today (I'm usually up at 6am, got up today at 11).<p>So yeah ... fear of breaking the software isn't unfounded.
The general principle in this article is a good one, but the specific scenario he described does not have to happen.<p>Be granular in how you check in your changes, and backing things out (especially loosely coupled code like debug logging and senseless exception handling) carries low to no risk.<p>I became good at this when emacs vc-mode made it easy.
This happens to me all the time when I am venturing into new territory with a language or framework I have little to no experience with and only the docs to guide me.<p>I can be 100% certain I found out what caused my bug, or how my code should really work. But I am iffy about taking out the superstitious and useless changes I made while I should have probably walked away for a bit... Changes that didn't help but didn't break anything either.
<i>I’d suggest that this cruft is among the most insidious forms of technical debt in that it’s held in place by a lack of understanding and fear to modify the program, rooted in superstition rather than reason.</i><p>"insidious", "technical debt", "lack of understanding", "fear to modify": agreed!<p>"rooted in superstition rather than reason": disagree...<p>My primary reason for not breaking it has always been lack of time. There were many times I encountered something I would have loved to have rewritten, but it would have thrown the rest of my schedule off. If I have 27 open tickets, 3 bosses, and 9 customers breathing down my neck, the last thing I need is some clusterfuck I broke and can't put back together fast enough. That's a mistake you only make once.