It's a gamble. It's always a gamble. What you have to realize is that you are gambling, and consciously think what's the probability of payoff vs cost of finding out if you were on the right path. Not everything is a pure loss, sometimes you figure out what should be done differently to make it work.
Debugging and designing new stuff is very different. For the latter the most important thing is to split the problem in ways that can be solved with a compact set of well interacting things. This takes a long time to get good at. If someone else does it quickly, they have either have a lot of experience, or very good intuitions. All you can do is ask how they did it and see if you can see the picture they're describing.
For debugging, sometimes you have a hunch and you're free to test it out--just be aware of how much time/effort that will take if it doesn't work out. You should always have a way of narrowing the problem so that regardless of the outcome of a step you're looking at smaller remaining set of possibilities. Imagine all the different things that could possibly (and almost impossibly) contribute to the bug, and rule them out one by one in order of likelihood or reduction of search space.
Another good way to solve certain problems more simply is to go outside the current system of thinking. e.g. Instead of doing a complicated computation at runtime, precompute many things and use those at runtime. You don't always have to solve a problem as presented, everything in software is very much up for changing, e.g. a not-so-common way is contributing to the opensource software you use in your stack that's part of the problem you're facing.
I think one thing that I do that maybe not everyone does much is, in the back of my mind keep thinking about other possibilities, that I might be wrong, that there may be a better way of doing it than what I'm doing now. Those thoughts are not negative and they don't take energy or motivation away from what I'm doing, though sometimes one new idea might seem good enough to pause what I'm doing, try that first, and come back if still not well solved.
Sometimes people get on the track of thinking of complex solutions first because it follows a pattern of other complex solutions that have worked in the past. One of the things I always think is, what is the simplest thing that might mostly work. Often a proof-of-concept or prototype of that thing, then lets you refine it an take care of the parts that it didn't with not too much complexity. e.g. caching to amortize cost of computations, if a cache can give the right answer X% of the time, then you only have to do the long/hard thing 100 - X% of the time which might be good enough. Or you can have a shared cache with part of the computation and only have to do the remaining parts every time for each case.
Talk to people about your approach/ideas before "spending a few days" on them. Of course you wouldn't know that you would end up spending that much time, so the only good way is to always talk about your approach/ideas that way some of them can be adjusted before spending too much time. If you can't frequently have realtime or semi-realtime Slack chats, write an issue description of your approach and get feedback. Even the exercise of writing can clarify your own thinking in your mind. Try to write concisely instead of stream-of-consciousness storytelling.
Other than practice and experience over time, realize that different people gravitate to different aspects of software development/engineering. Use your strengths, work on some of areas where you can improve but don't get hung up on any single area that some others seem to do well in that you haven't. You're not going to be as good or better at everything even with time/effort.