How do you get better at that other than practice/over time?
As an example, I had to debug something, I spent a few days on it, someone else comes in and finds the solution within an hour.
If I can describe it as a tree/layers, they started at A and I was deep in the weeds of implementation in F.
Another effective way to improve your ability to see the bigger picture is to gather input and perspectives from others. This can help you to consider different angles and to gain a more well-rounded understanding of the situation.
Additionally, taking breaks and practicing mindfulness can also help you to be more aware of your thoughts and to better understand the bigger picture.
Finally, Reflecting on your past mistakes can also be an important learning tool and can help you to avoid making the same mistakes in the future.
> Debugging is one of the most creative and intellectually challenging aspects of programming. It can also be one of the most frustrating. To a large extent, the problems that people face debugging programs are not so much technical as they are psychological. To become successful debuggers, you must learn to think in a different way. There is no cookbook approach to debugging, although Nick Parlante’s 11 Truths of Debugging (given below) will probably help. What you need is insight, creativity, logic, and determination.
https://cs.gmu.edu/~tlatoza/papers/UsingHypothesesAsADebuggi...
> developers often formulate incorrect hypotheses, resulting in wasted time gathering evidence and looking at irrelevant code that ultimately does not lead the developer closer to the true defect . When they fail to find a correct hypothesis, developers often look for help, mitigating the need to generate their own hypotheses. Seeking help from an experienced coworker is one way to find the correct hypothesis. Unfortunately, developers may not always find their coworkers available. One might also expect that, given the wealth of developer information available on the internet, finding hypotheses might be easy.
Book recommendations (2015), https://news.ycombinator.com/item?id=9242384
Systemantics (1975, https://en.wikipedia.org/wiki/Systemantics) and Fravia (2009, https://en.wikipedia.org/wiki/Fravia) may be useful.
People will invade one or the other, but rarely both.
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.