For example, I found that some of the bikeshedding was a healthy and fun mental exploration, a very zen use of natural gifts that take very little energy and are more like meditation. So I was more hands-off about it being an issue when that was the case, and instead tried to capture more of the value from what I had done, so I could reuse or leverage it in the future.
In other cases the lack of a useful framework for getting up to speed is a really beautiful setup for the more frustrating form of bikeshedding. I had this happen once with contracts, because a client changed their scheme for coming to contract. God the amount of stuff I learned about LibreOffice while spinning my tires in the mud! In that case I developed a completely speculative framework for navigating contracting method changes, after all was said and done. It helped a lot later.
Prioritization is also more variable or modular to me now. I prioritize most often depending on ease of access to tasks, rather than importance.
Good luck, I hope some of this helps.
No, I can't tell you how I developed this. I had it at least by the time I was in university. (It came in really handy during tests - it kept me from wasting too much time on a wrong approach to a problem.) So, unfortunately, I can't give you any actionable advice. (Unless you get that feeling also, in which case the advice is, when it triggers, don't ignore it.)
Do you want to pay for all that time and be where that is for that long? Is that trip worth it?
Strive to keep that problem statement small, focused on the highest ROI problem.
Break the project down into milestones. That will tell you what to work on, and what not to work on. Set achievable deadlines to keep yourself accountable and laser focused on forward progress.
If a bikeshed question arises, ask whether it can be deferred and easily changed later. If so, defe9r it.
If the bikeshed question cannot be deferred, build consensus with the _key_ stakeholders. Try to keep that set of people small (just those with relevant expertise, and those with authority) and don't worry about pleasing everyone, trying that will be wasteful. Don't worry about the outcome, if its a small part of the overall ROI.
Projects don't have to solve all problems, just effectively improve the status quo.
A lot of times somewhere in the middle you declare technical debt bankruptcy by moving on to a new project and you never have to pay down any technical debt.
Other times the product grows and scales and you have to manage paying down the technical debt. Here you can even use the cheesy financial advice you hear on the radio about paying down debt. Considering what might be most likely to compound, what debt you might be able to later write off and avoid paying it now.
There is a constant push and pull of how much technical debt to take out, when to pay it down, and when to write it off.
Like, literally, if I have to make an arbitrary choice, I'll look at everyone else in the space and see what they're doing.
I'm not developing standalone projects, I'm developing plugins, for an imaginary suite that consists of all the other software in common use.
Like, plaintext vs database. My first factor to consider is Git, syncthing, and other such tools. Git likes plaintext. If it's something that should be versioned, synced, partially updated, etc, I'll probably use text files.
Coding style? Use the official one for the language. There isn't one? Use whatever is most common in your top 10 favorite libraries.
Choosing a framework? I look at what's mature and still popular and doesn't seem to have lots of people migrating away from it. I'm looking for stuff that will be around in 10 years, and where questions can easily be googled.
Totally arbitrary API structuring choice? If 2 or 3 other people do something similar, why not do the same?
There's enough value in standardization that it doesn't make sense to give it up for no reason.
Elegant beautiful stuff is still stuff you have to maintain and document and explain and argue about. Follow existing standards, and you can just point to PEP-8 and say "We use that" or "Our API is based on X, if you want to add something see that for a reference".
From the big to-do list a selection is made for a short work-in-progress list, largely in consultation with the project client. I only work on the items on the work-in-progress list.
The work-in-progress list itself is roughly ordered by importance, but may be shuffelt around a bit according to new circumstances, insights or favourable opportunities (such as implementing one thing on the side when I am actually implementing something else).
If the work-in-progress list becomes too long because the client or myself think some new ideas are really urgent or important, some other items from the work-in-progress list have to be moved back to the big to-do list. Following the Pareto principle, this may also happen for items which have not been completely but sufficiently implemented.
From time to time the work-in-progress list will be completely revised.
My guiding adage is: You can only work on a single thing at a time; always pick the most important.
Then such a new conception would lead to an inevitable finality that just simply dampens any latent bikeshredding tendencies
-it has 4 wheels attached, task is done.
vs. bikeshedding
-what is the tire pressure? is the tread thickness even everywhere, is the static torque on wheel bearings uniform.