I've been considering the topic of solving problems too early for quite some time now, and you very effectively communicated this point; thank you for that clear insight.

Relatedly and at the same time, I sometimes have a hard time figuring out when the right time to 'solve' the problem is. Speaking generally, if left unchecked for too long, it seems like more effort to go through and find instances of the problem and create a valid solution and then apply the solution, then if I am able to spot the reoccurring problem after only a few instances. This is particularly worse when I go back and solve the problem in a few areas, but there are more areas that I've missed (and now I have some spots with the solution, some without, and everything is messy). I suppose I need to spend more time after creating a solution to see if it's applicable apply anywhere else (but then that's more time refactoring than actually working on the problem at hand).

Those are genuinely hard problems you describe, so don't feel bad about struggling with them.

Personally I am very focused on refactoring. When in doubt, if I can improve the code, I will! I don't know that that's "right", but it's how I live.

Is one effective method perhaps to carve out a consistent, say, 5% of the day to focus on this cross-polination of implemented solutions?

This could work (perhaps on a more weekly level for me). I would have to note the solutions and problems as I come across them and put them into a backlog, otherwise I'll definitely forget about them (until I run into them again, haha).

This does go back to topic focus though. Regarding programming specifically, I generally will have a topic (such as a feature enhancement). If I implement a new solution to a problem, it's not clear-cut to me if I should go and implement that solution everywhere relevant during the current topic, or if I should wait until a more tech-debt rework to clean things up a bit. My inclination is to focus on rework only during those tech-debt reducing stints. I really should figure out a clear and well-defined process for this.

This is a good generalization but I worry that it's too broad. I.e. if your lifeboat is sinking, it's too late to find a better lifeboat.

But at that point your problem isn't needing a better lifeboat, the problem is why it's sinking. At this point solving the problem of why it's sinking is the problem you've got, solving it before you had that problem seems silly.

Brilliant