This is a great question. And I think it isn't just senior programmers that run into this — addressing it early can be a great way for a learner to accelerate their skill development.
There are two sides to this issue - one that is bad and one that is actually good.
Bad - Picking the wrong solution
Here's an example — as an inexperienced developer, you may have only really solved two problems before, problems A and B. At this point, you know there are problems you don't know, but given the lens of your own experience, a lot of what you see looks like it might be A or B.
Along comes a new problem. To you, this new problem looks like problem A, so you solve it the way you usually solve A. Something doesn't feel right, and it takes longer, and as you work you end up realizing this is a new problem, C. It's a variation of A you didn't know existed.
So what do you do to not make this mistake again? Two things:
- Figure out what was different about this new problem. Figure out what approaches may have worked differently and why.
- Catalog this problem away and move on to solving more new problems.
This should help you naturally solve this problem. By the time you have 10 years of experience, you are familiar with problems A through Z and your repertoire of solutions is extensive.
Good - Efficiency
In the real world, with deadlines and limited resources, using what you know isn't always bad:
- At the onset of the problem-solving process, you compare the new problem to all problems you know.
- You'll attempt to recognize the signs and decide which problem set this looks like.
- If a 100% match can't be made, an experienced developer will weigh the risk of spending more time in discovery against the risks of a possibly flawed execution. If the risk of wasted time is too high, then you just go ahead with what you know.
That isn't a bad thing - it's using risk analysis to choose efficiency over 100% accuracy. It's done every day and we'd all be tied up in things that aren't getting us anywhere if we didn't do it.
So, to answer your question:
As a programmer with a decent amount of experience, how can one combat this tendency to always approach problem solving from "tried and true" paths from past experience?
- Keep looking for and cataloging new problems
- Get better at selecting the right solution for the problem; instead of just knowing which solution, know why it's right.
- Practice and hone your decision-making skills. Sometimes efficiency is the right choice, and getting better at recognizing those times will lead to measurable real-world advantages.