What's your Modus Operandi for solving a (programming) problem? [closed]

Question

Step away from the computer and grab some paper and a pen or pencil if you prefer.

If I'm around the computer then I try to program a solution right then and there and it normally doesn't work right or it's just crap. Pen and paper force me to think a little more.

First, I go to one bicycle shop; or another.

Once I figure nobody invented that particular bicycle,

• Figure out appropriate data structures for the domain and the problem, and then map needed algorithms for dealing with those data structures in ways you need.

• Divide and conquer. Solve subsets of the problem

This algorithm has never failed me:

1. Take Action. Often just sitting there and being terrified or miffed by the problem will not help solve it. Also, often, no amounting of thinking will solve the problem. So you have to get your hands dirty and grapple with the problem head on.

2. Test. Under exactly what conditions, input values or states, does the problem occur? Make a mental model of why these particular conditions might cause the problem. Check similar conditions that don't cause the problem. Test enough so that you have a clear understanding of the problem.

3. Visualise. Put debug code in, dump variable contents, single step code whatever. Do anything that clarifies exactly what is going on where - within the problem conditions.

4. Simplify. Remove or comment code, poke values into variables, run particular functions with certain values. Try your hardest to get to the nub of the problem by cutting away the chaff or stuff that doesn't have a relevance to the problem at hand. Copy code into a separate project and run it, if you have to, to remove dependencies.

5. Accept. A great man said: "whatever remains, however improbable, must be the truth". In other words, after simplifying as much as you can, whatever is left must be the problem, no matter how bizarre it may seem at first.

6. Logic. Double, triple check the logic of the problem. Does it make sense? What would have to be true for it to make sense? Is there something you're missing? Is your understanding of the algorithm wrong? If all else fails, re-engineer the problem away.

As an adjunct to step 3, as a last resort, I often employ the binary search method of finding wayward code. Simply comment half the code and see if the problem disappears. If it does then it must be in that half (and vice versa). Half the remaining code and continue.

• Google is great for searching for error messages and common problems. Somewhere, someone has usually encountered your problem before and found a solution.

• Pencil and paper. Pseudo Code and workflow diagrams.

• Talk to other developers about it. It really helps when you have to force yourself to simplify the problem for someone else to understand. They may also have another angle. Sometimes it's hard to see the forest through the trees.

• Go for a walk. Take your head out of the problem. Take a step back and try to see the bigger picture of what you want to achieve. Make sure the problem you are 'trying' to solve is the one your 'need' to solve.

• A big whiteboard is great to work on. Use it to write out workflows and relationships. Talk through what is happening with another team member

• Move on. Do something else. Let your subconscious work on the problem. Allow the solution to come to you.

1. write down the problem
2. think very hard
3. write down the answer