- What are you trying to solve? Define the problem well.
- Break the problem down to essential and smaller parts.
- Prioritize order of solving the parts. Do necessary research.
- Work on solving each part one by one. No distractions. Get rid of parts that are non essential.
- Optimize. Document. Share solution.
1. What are you trying to solve? Define the problem well.
I use Height for all my project and personal tasks/ideas I work on.
In there I clearly define the subtasks and all the necessary information. Just lay it all out. If something is not yet clear, think it through alone or with like minded friends in Excalidraw. High level diagrams.
For personal tasks and keeping my brain fresh of memorizing things, I use 2Do, GitHub issues and
TODO:'s in the code. Write anything that comes to mind that's of value, always! Don't keep non directly actionable things in your brain RAM. Only thing you should keep in your brain RAM is the actual problem or subtask of the big problem you are solving.
Going on walks or having naps and even relaxing with friends whilst still having the problem at back of your mind is super useful as your brain is actually processing the problem in background and can give you novel insights.
Just try to be clear of what you're solving and why!
2. Break the problem down to essential and smaller parts.
As mentioned, I use Height for this now and its subtasks feature is lovely. Want to build a Height like app that sits on top of GitHub issues soon as that would be even better.
Example task with subtasks
Month view of things to do for a project
Most important part in this step is just to make sure that subtasks are all actionable. Sort by priority and then go at it, one by one.
Can look like this. Here LA and epictools are two tasks/projects with subtasks.
MindNode lets you focus in on one of the nodes for better focus.
Can also use arrows with descriptions for more high level views. Above is example of one brainstorming session.
Often times I don't need to go this deep into sketching everything out. And just working in the code editor and outlining the task in Height/GitHub is enough. Or 2Do (as note).
If through this process, you find some part of solving the task, not useful or unneeded, remove it! Why Tesla removed Radar and Ultrasonic sensors is nice overview of this in action.
Minimal viable working thing first!
3. Prioritize order of solving the parts. Do necessary research.
In this part, assuming you have things in order and well defined (as much as possible). Do necessary research. Is this problem already solved by someone? Can we just use it or integrate?
4. Work on solving each part one by one. No distractions. Get rid of parts that are non essential.
If there are no viable solutions already for the problem. Do the work to solve it!
Each subtask, one by one. No distractions during work focus sessions.
I use great tools to make the process of solving tasks as smooth/fast as possible.
Know how to effectively ask questions so as to respect other people's time and maximize chances of getting a good answer.
Often times I reach out to authors of certain libraries directly, sponsor them for their work and ask for help on my issue. GitHub sponsors are great for bringing attention to certain issues.
5. Optimize. Document. Share solution.
Once you have your first working solution that solves the thing. You can start optimizing the solution, if you actually need the optimization!
Then document everything related to it, hopefully you also documented the process of building too. Especially why certain key decisions were made in certain parts of design/solution.
And share it! Most fun part as you can then get even more feedback. Can also start sharing early to get early feedback or help with the research part of solution seeking.
As far as knowing how to prioritize on what to work on. Minimizing regret is always a good mental model for choosing problems to solve. Will I still be worried about this a year from now? If so, it's probably important and worth worrying about and solving. If not, let it go and move on. Better side on making decisions and reversing in light of new knowledge than falling victim to fear or risk.
- I learned about the Feynman technique. Just write down how the thing you’re trying to learn works (a bug, a technique, anything) until you hit a wall in your understanding. This makes the boundary of your understanding explicit. Often, it’s surprising how much you actually do understand before hitting the wall, but before you build confidence, there’s a bias to assume the amount you don’t understand is greater than it really is. Make the boundary explicit, and then you have a specific point to push forward from, rather than kind of a cloud of doubt and anxiety. This made it clear that I knew more than I felt I knew, and at the very least helped me hone in on specific questions to ask.
- Usually the easiest way to solve a problem is to not have it.
- When someone comes to you with a problem, before you start to fix it, ask “What are you trying to achieve?”
- Reframing your problem can be a potent way to find solutions. “How can I grow?” Open, generic, often not actionable. “What’s stopping me from growing?” Direct, specific, insightful, and it requires radical honesty and self awareness.
- When confronted with a problem I don’t understand: don’t just guess. Investigate.
- The first step to solve any problem is to recognize what problem spaces you are in.
- Tell me what would have to be true to do x by y.
- Debugging technique I've been perfecting recently: when it's late at night and I've been banging my head on some bug (but have my mind fully wrapped around the symptoms), go to sleep. In the morning, usually solve it within 15 minutes. Subconscious really knows what it's doing.
- When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. But if you keep going, and live with the problem and peel more layers of the onion off, you can often times arrive at some very elegant and simple solutions.
- A problem well-defined is half solved
- Resource + time constraints actually help if you do lots of projects. You don't have to time to go very deep, so you pick the most simple and practical solution for every problem, and that's usually the best. No overengineering.
- Ask HN: What has made you a better problem solver in software engineering? (2019)
- Pen and Paper Programming: what notation, if any, do you use? (2020)
- Tools/practices to manage deeply nested thought-stacks? (2020)
- Problem-solving tips
- How to scope work (2020)
- Problem solving - Introspecting on improving my product problem solving skills.
- Ask HN: How to improve my abstract thinking? (2020)
- Ask HN: How can I “work-out” critical thinking skills as I age? (2020)
- Ask HN: How to Think Clearly? (2020)
- Problem Solving Techniques (2020)
- Start with pen and paper (HN)
- 4 Different Perspectives to Solve Problems (2020)
- Hammock Driven Development - Rich Hickey (Summary)
- Adding is favored over subtracting in problem solving (2021) (HN)
- How to Learn Complex Things Quickly: A Guide (2021) (HN)
- Using Paper for Everyday Tasks (2021) (Lobsters)
- Move fast, but understand the problem first (2021) (HN)
- Ask HN: What problem are you close to solving and how can we help? (2021)
- How I Write Code: Pen and Paper (2021) (HN)
- I Don't Understand This (Yet) (2021) (HN)
- Decomplication: How to Find Simple Solutions to Hard Problems (2016)
- Focused and Diffuse: Two Modes of Thinking (2019) (Tweet)
- Getting Unstuck (2021)
- How to think like a detective (2021) (HN)
- Elon Musk's 5-Step Protocol for Successful Engineering (2021)
- The programmer's brain in the lands of exploration and production (2021)
- System Dynamics: Systems Thinking and Modeling for a Complex World (2020)
- A Few Notes on Problem Solving (2022)
- Problem solving strategies in a graduate real analysis course (2010) (HN)
- How to program it
- Practical Guide to Solving Hard Problems (2022) (HN)
- Ask HN: Books recommendations on developing critical thinking? (2022)
- Contributing to Complex Projects (2022)
- Developers spend most of their time figuring the system out (HN)
- Questions for a new technology (2019)
- What “work” looks like (2022) (HN)
- Elon Musk's 5-step engineering process
- Only Solve One New Problem At A Time (2022)
- Ask HN: Which books have made you a better thinker and problem solver? (2022)
- Ask HN: How do you approach a problem you are not sure has a solution? (2023)
- My Approach to Building Large Technical Projects