YAGNI.
Hesitation to avoid unnecessary work, sure. But not to anticipate future requirements.
The number of times I've had to fight a fancy design that left expansion points / abstractions for future features that were never needed (or not in the form the designers expected) enormously outnumber the times any such thing was useful.
Just make the code do its current job in the simplest way possible. That's the easiest design to expand later.
You will never get it "right" the first time as much as you can avoid doing it "very wrong".
The key is to have enough experience and taste to appropriately break down problems into pieces that encapsulate the volatility of the various domains.
Then you can refactor easier which should be the real goal.
Prune and tend to the garden.
Some people see effective people making 'bad' decisions and miss the bit where there were eight bad ways to accomplish something and they rejected 6 as being more work overall. Then they take their misreading of the situation as justification for YOLOing decisions to avoid analysis paralysis.
Is a reason like, "being built like shit by the cheapest contractors that won the bid" ever a good reason?
My work is huge on what I call, "fire, forget, then rewrite." Basically, we have tons of legacy apps that have lifespans of like 10 - 20 years, many of which never receive a single update. So, they eventually get old and unsupported enough that it's honestly just easier/quicker to rewrite them.
And in case you were wondering, yes, I work in Gov..