More often than not I end up three or four tasks deep while trying to fix a tiny issue.
I know some are tired of AI discourse, but I found AI can help to sharpen the tools but at the same time I find that my scope grows such that dealing with the tools takes just as much time but the tools have more features "just in case" and support platforms or use cases that I won't often need, but it feels easy enough to just do, but then as I said it still takes long in total.
It's all mostly an emotional procrastination issue underneath it. Though that can go both ways. Sometimes you procrastinate on thinking about the overall architecture in favor of just making messy edits because thinking about the overall problem is more taxing than just doing a small iteration, sometimes you procrastinate on getting the thing done in favor of working on more tightly scoped neat little tools that are easier to keep in mind than the vague and sprawling overall goals.
Making messy edits is a bet on previous code quality. If you have paid off enough technical debt, you can take another "technical loan" and expect the rest of the owl to still function despite the mess being introduced. If things are already messy, there's always a risk to make the fess incomprehensible and failing in mysterious seemingly unrelated ways, with the only way to fix it being to git reset --hard to the prior point, and do a more right thing. But the time would have been wasted already.
My approach is usually to timebox it, and cut the losses if an acceptable solution is not yet in sight when the time runs out.
Not that you can't get one into a non-working state, that is, of course, trivial but with the lone exception of deleting data, you can always restore a computer, the only tool being needed is some kind of boot disk.
(Compare that to breaking a literal hammer, you'd need a pretty specialized set of tools handy if you wanted to actually restore it)
You are going to pay it anyway, its not an "if" its a "when"
Excellent follow-up advice: now stop fixing your tools, and go fix your actual problem instead. I try to follow it in my daily work, with noticeably less success.
My favorite framing, from Kent Beck: “first make the change easy, then make the easy change.”
In my experience you're going to want a sharp axe later in the process, once you've dulled it.
Not sure if that ruins the analogy or not.
So they never make the change easy because every change is easy to them... until the lack of structure and re-use makes any further changes almost impossible.
What are the incentives for these developers? Most businesses want trees on trucks. That’s the only box they care to check. There is no box for doing it with a sharp axe. You might care, and take the time to sharpen all the axes. Everyone will love it, you might get a pat on the back and a round of applause, but you didn’t check any boxes for the business. Everyone will proceed to go through all the axes until they are dull, and keeping chopping anyway.
I see 2 year old projects that are considered legacy systems. They have an insurmountable amount of technical debt. No one can touch anything without breaking half a dozen others. Everyone who worked on it gets reasonable rewarded for shipping a product, and they just move on. The business got its initial boxes checked and everyone who was looking for a promotion got it. What other incentives are there?
I don't think every company is like this though. E.g. Google and Amazon obviously have spent a mountain of time sharpening their own axes. Amazon even made an axe so sharp they could sell it to half the world.
i tried every no-code automation platform (make, airtable, n8n) for a content pipeline i was building. they all break the moment you need to run it more than twice a day at any real scale. weird rate limits, silent failures, state management nightmares.
ended up just writing python scripts that call APIs directly. less "elegant" but infinitely more debuggable. the fix-your-tools moment for me was realizing the tool itself was the problem -- sometimes fixing means replacing with something simpler and more transparent.
Kenneth Stanley's book "Why Greatness Cannot Be Planned: The Myth of the Objective" is dedicated to this phenomenon
The hard part is convincing yourself it's worth the upfront time. There's always "real work" that feels more urgent than fixing your build script or editor config.
I'm not completely against debuggers, but in my experience they only are useful either to get the trace of the problem when it first occurs and then use static analysis until you have a theory the debugger can prove/disprove - but only prove/disprove that theory don't keep looking: you will feel productive but in fact be spinning circles
Times when I was more familiar with the program or there were fewer variables to track it was less helpful
Measure of progress for me is formulating and answering questions. Sometimes trying to answer a question leads to formulating sub questions.
You're welcome.