- Write down the problem, in an unambiguous way
- Think real hard. Think about odd ways to solve it, things you wouldn't tell other people for fear of being laughed into the next century. Look at simple things, look at really complicated intricate solutions. Then talk to others. Talking to others will allow you to crystallize some of the ideas you have, and produce more ideas for you to think about. Repeat until you have an answer you can write down.
- Write down the solution.
Pólya suggests the following steps when solving a mathematical problem:
- Understand the Problem.
- Devise a Plan.
- Carry out the plan.
- Look back on your work. How could it be better?
If this technique fails, Pólya advises: "If you cannot solve the proposed problem, try to solve first some related problem. Could you imagine a more accessible related problem?"
Polya mentions that there are many reasonable ways to solve problems. The skill at choosing an appropriate strategy is best learned by solving many problems. You will find choosing a strategy increasingly easy. A list of strategies/heuristics could include:
- Analogy: Can you find a problem analogous to your problem and solve that?
- Generalization: Can you find a problem more general than your problem?
- Induction : Can you solve your problem by deriving a generalization from some examples?
- Variation of the Problem: Can you vary or change your problem to create a new problem (or set of problems) whose solution(s) will help you solve your original problem?
- Working backward: Can you start with the goal and work backwards to something you already know?
- Auxiliary Problem: Can you find a subproblem or side problem whose solution will help you solve your problem?
- Decomposing and Recombining: Can you decompose the problem and "recombine its elements in some new manner"?
- Other suggestions include: Guess and check, make an orderly list, draw a picture. eliminate possibilities, use symmetry, use a model, use direct reasoning , use a formula, solve an equation or be ingenious.
Here is a list of David J.Agan’s timeless and universal rules of debugging (as it applies to Computing + other disciplines of Science and Engineering). As the author notes in the book - Memorize them. Tape them to your wall. Tape them to all of your walls.
- Understand the System: Read the manual. Read everything in Depth. Know the Fundamentals. Know the road map. Understand your tools. Look up the details.
- Make it Fail: Do it Again. Start at the Beginning. Stimulate the Failure. Don’t Simulate the Failure. Find the uncontrolled condition that makes it intermittent. Record everything and find the signature of intermittent bugs. Don’t trust Statistics too much. Know that “that” can happen. Never throw away a Debugging tool.
- Quit Thinking and Look: Get Data First. Don’t just do Complicated repairs based on guess game. See the Failure. See the Details. Build Instrumentation in. Add Instrumentation on. Don’t be afraid to Dive-in. Watch out for Heisenberg. Guess only to focus the Search.
- Divide and Conquer: Narrow the Search with successive Approximation. Get the Range. Determine which side of the Bug you are on. Use Easy-to-use test patterns. Start with the Bad. Fix the bugs you know about. Fix the noise first.
- Change One Thing at a Time: Isolate the key factor. Grab the brass bar with both hands (i.e., understand what’s wrong before fixing). Change one test at a time. Compare it with a good one. Determine what you changed since the last time it worked.
- Keep an Audit Trail: Write down what you did in what order and what happened as a result. Understand that any detail could be the important one. Correlate Events. Understand that audit trails for design are also good for testing. Write it Down!
- Check the Plug: Question your assumptions. Start at the Beginning. Test the Tool.
- Get a Fresh View: Ask for Fresh Insights (aka explaining the problem to a mannequin/dummy). Tap expertise. Listen to the voice of Experience. Know that help is all around you. Don’t be Proud. Report symptoms (not theories). Realize that you don’t have to be Sure.
- If you don’t Fix it, it Ain’t Fixed: Check that it’s actually/really fixed. Check that it’s really your fix that fixed it. Know that it never just goes away by itself. Fix the Cause. And, fix the Process.
- https://www.math.utah.edu/~alfeld/math/polya.html
- https://debuggingrules.com/
- https://fs.blog/an-algorithm-for-solving-problems/
- https://www.calnewport.com/blog/2012/06/18/impact-algorithms-strategies-remarkable-people-use-to-accomplish-remarkable-things/