There's one big rule I tend to follow in my work that I think a lot of people could benefit from: I wait until problems hurt before I solve them.

The scale of this could be large, from what database management system do I use, to tiny: Where should I put this new function? Premature problem solving leads to overcomplexity and subpar decisions that are hard to change. Worst of all, it's completely avoidable by solving your problem at hand over solving what you think your problem might become.

Some ideas

Tech Choices

Say you're starting a new project, and you don't know what your data will look like. Rather than making assumptions about what you think your needs may be, pick the simplest or most familiar database system. Then you can quickly and cheaply make a more informed decision and pivot if and when your database choice starts to hurt.

The same goes for other tech choices. When it's early or when requirements aren't totally nailed down, pick something simple that makes it easy to pivot from if and when challenges arise

Code organization

If you write a utility function that you're not sure where to put, just put it in the file that uses it. It'll be exactly where you'll think to look for it. Once your application grows and other modules are using that function, you can move it to its own file. If you end up with more related functions, you can group them together at that point — but only at the point you find it difficult to find one, ie. when the lack of organization actually hurts.

A non-work scenario

If you bought your first video game, would you buy three game bins, label one "A-H", another "I-P", and another "Q-Z", and put the one game in one of those bins? Of course not! You'd just put that one game on your TV console and wouldn't think about organizing until you have enough games that you have trouble finding what you're looking for.

The same goes for your codebase: Don't over-organize before things become hard to find.

Stop premature problem solving

Better decisions

Reactive problem solving keeps things simple and usable before your problem arises, and creates better solutions in the end. By the time you're solutioning, your problem is well defined and you're solving based on facts rather than guesses.

Easier to pivot

By deferring your problem solving, it'll be easier to implement the correct decision since things were kept simple. It's easier to add complexity than to refactor it.

Better focus

By saving theoretical problems for when they hurt, you create bandwidth to focus on the real problems in front of you.

Frame painful problems positively

It's common to react to a new problem as a bad thing and think "I should have solved this already."

A better reaction: "Now is the right time to fix this."

Give it some time

It can take some time to get comfortable with not having potential solutions to every one of your potential challenges, but once you get comfortable with it, I think you'll find your work will be higher quality and lower stress.