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.
Some explanations of yak shaving split it into a complex form of procrastination and also necessary annoyances - friction - obstacles.
Sharpen your Tools often falls into the latter category, and it's always useful to question whether those 'necessary annoyances' are actually necessary.
It is, like you say, not always necessary to tackle those annoyances right now. But it is a situation where both the Campsite Rule and the Rule of Three have some domain. As a person whose entire job is about writing code to replace tedious and error-prone human tasks, you need to interrogate yourself any time you start thinking, "This is my life now." Because if anyone has the power to say 'no', it's us.
It's always worth spending 12-15 minutes most times you do a task that you have to do over and over again in service of trying to reduce the task from ten minutes to five or to zero. The reward for engaging in the task more fully rather than putting it off until it has to be done is that you're working toward a day when maybe you don't have to do it at all (you've automated it entirely or you've made it straightforward enough to delegate).
Hal's example is so funny because he's using both arms to scoop in everything from Column A and Column B at the same time. Everybody gets a laugh. A couple of those tasks actually had to be done. A couple could have gone on the shopping list.
For example, I want to use ES6 modules on my website, then esbuild to compile them. However masonry.js breaks it, and instead of fixing it, I decided to get rid of it, but that breaks the layout of the /guides page, and while I'm there I might as well reorganise the list of guides.
So now I'm on week 2 of the switch to ES6, but I ended up redesigning a page, writing a bunch of tests, fixing unrelated UI bugs, making a few UX fixes, making changes to the static site generator, etc etc.
I get to do that because I'm self-employed and thinking long-term, but if I was at $PREVIOUS_EMPLOYER doing sprints, my boss would be wondering why I spent an entire sprint on this simple task.
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"