Ask HN: How to get better at higher level thinking?

[ge96]

A couple times recently I have burned time doing the wrong thing. It's that thing where you step back and think about the bigger picture and have an easy solution.

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.

[quantisan]

One way to improve your ability to step back and think about the bigger picture is to make a habit of regularly reviewing your goals and priorities. This can help ensure that you are always working on the most important tasks and that your efforts are aligned with your overall objectives. Additionally, it can be helpful to break larger tasks down into smaller, more manageable chunks, and to make a plan for how to complete each step.

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.

[ge96 → quantisan]

Yeah I have a problem of burning hours due to getting stuck/trying something over and over.

Reflecting is good. It would be nice if it wasn't a shame obsession.

Also yeah you do want to ask questions ideally before days are spent. But I wanted to do it myself.

[sargstuff → ge96]

Learn how to drink prune juice like a Klingon? [1]

[1] http://www.startrek.com/database_article/prune-juice

    http://memory-alpha.fandom.com/wiki/Prune_juice

[sargstuff → ge96]

So, take the anthology approach.

"Surfaces and Essesnces, Anthology as the fuel and fire of thinking" by Dougalas Hofstadter & Emmanuel Sander.

[walterbell]

https://web.stanford.edu/class/archive/cs/cs106a/cs106a.1134...

> 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.

[ge96 → walterbell]

thanks I will read through these, yeah that's my issue going down an irrelevant path

[fallowkevin]

Keep two diaries. One on paper, one on the computer.

People will invade one or the other, but rarely both.

[ge96 → fallowkevin]

yeah I write a lot, mostly because my memory is bad

[karmakaze]

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.

[ge96 → karmakaze]

> very good intuitions

yeah that's it, I asked "why did you go the way you did"

> 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

yeap... I have a bad habit of spiraling/panicking going in circles

> current system of thinking

> You're not going to be as good or better at everything even with time/effort.

Yeah ego, I just try not to reach out all the time... be self reliant but yeah days is too long.

Thanks

[karmakaze → ge96]

Glad some of it made some sense and could be applicable. TBH, I don't know how I got to be able to do what I can now, other than have decades of first-hand, trial and error experience and opportunities to work with people much smarter/experienced than me.

Edit: one thing that I've been finding lately is talking things out, whether with other sr or even some jr devs, can make discoveries or uncover avenues to look into that I wouldn't have come up with on my own. So just because you reach out, it doesn't mean they can give you "the answer" but you can find one together.

[ge96 → karmakaze]

not rubber duck debugging but yeah I get ya