Hacker News new | ask | show | jobs
by targafarian 657 days ago
For me this is a set of general strategies for breaking down problems. Here are some I use. (Apologies if these aren't all orthogonal to one another; they just feel different when I'm thinking of how to break a problem down.)

1. Break down the steps. Can you find a recipe of steps for achieving the thing? Then start with the first step. Maybe that's a small enough task. Maybe you don't have to perform all steps in order, and you can find a small-enough step to do next.

2. Isolate the fundamental challenges. There is often a tough nut to crack within the problem. Can you isolate that from the rest of the project, and turn it into its own thing (I like to cast this as a "toy" problem)? When I say "isolate," I mean to remove all unnecessary complexity to getting at the fundamental issue. Suppose I want to figure out how to create a robust messaging network. There might be user interfaces and caching and different kinds of messages and different networks and different failure mechanisms and performance issues and ... So just create a "toy" at each step: First, simply send & receive a message. Don't worry about performance or worry much about robustness. You now have a small task but whose completion achieves a fundamentally necessary part of the larger task. Finishing that will feel good--you have something that works!--and you've made real progress. You might find examples of others doing something similar to this basic task as well, so you can work on your own but then compare notes to others to gain insights on why others have solved similar problems differently than how you solved it (you might have come to something better, or not; either way, you now have understanding of the fundamental problems involved). Now you can grow that toy or take what you learned from the toy and apply it to the larger task.

3. Similar to 2, but maybe a different POV: The physics joke is approximating a cow as a perfect sphere to study its dynamics. Simply the hell out of a problem! Maybe it feels ridiculously simple. Fine; now you are working with something completely tractable. You can then add in complexity to your model one wrinkle at a time.

4. Do something that's actually easy even if i might not be "significant" from the "big challenges to getting this project working" POV. Maybe you've been frustrated for a week or two trying to solve the tough-nut-to-crack bit of the problem. Even your toy problem remains (what feels hopelessly) broken! Switch over to creating the GUI or something superficial but that is easily tractable yet yields something satisfying to you when you finish. Simply stepping away from the hard problem for a day or two can re-motivate you when you come back to the hard problem. That time can also give your mind time to process solutions in the background (many people--myself included--have an "a ha!" moment when not thinking directly about a hard problem). And you are still being productive, moving towards the end goal. You had to make a GUI anyway at some point. Might as well be when you are stuck on the hard thing and feeling frustrated.

Getting good at breaking down problems took me many years. I credit my physics education as being particularly helpful (training thinking of problems & solutions in their extremes and always connecting solutions back to "does it make sense"). But much of the above is also learning my own psychology of how I work and what/when/how I am motivated to work and in the best position psychologically to solve a problem. I expect this isn't too different for many people, but the details can vary from person to person.

1 comments

Thank you for the extensive explanation. The problem I mentioned starts rather earlier: say I have X big tasks. I need to split them (applying your described process or otherwise) into smaller tasks. BUT now I'm looking at X x2 tasks: the original X ones, each one getting another task of splitting it into smaller ones. The whole stack becomes only more overwhelming like this...
You end up with more smaller tasks.

A big part of the idea with my system is that you only identify 5 tasks at a time. Anything more then that and it becomes overwhelming. So the idea is to peel off the first 5 actionable tasks from your project(s), deal with those before thinking further about the project.

Yes this implies having a general sense of how to accomplish the project and the tasks involved, but no it does not mean you need to have a master plan with every step mapped out. Every 5 steps you get to re-assess and course correct.