The image above is the hand-out of the last talk I gave. Rubber ducks have long been known as one of the most effective debugging devices [1].
Very often, while debugging, you *know* that you are almost there. The problem is that, before you notice, the morning has gone by with you being "almost there". If you don't really get there after a couple of quick and dirty iterations and want to avoid wasting a morning "almost there", it is very useful to make explicit the steps that everyone takes while debugging: enter your notebook and the scientific method (quoting from Andreas Zeller's Why Programs Fail: A Guide to Systematic Debugging)
- Observe a failure
- Invent a hypothesis consistent with the observations
- Use the hypothesis to make predictions
- Test the hypothesis by experiments and further observations
- If the experiment satisfies the predictions, refine the hypothesis
- If the experiment does not satisfy the hypothesis, create an alternate hypothesis
- Repeat steps 3 and 4 until the hypothesis can no longer be refined
Keeping a written track of the steps is the key here. The advice is quite obvious, but we often forget about obvious things that work very well [2].
[1] This is not the only surprising ability of rubber ducks: http://en.wikipedia.org/wiki/Rubber_duck#Oceanography
[2] I'm writing this post after a most ineffective "almost there" afternoon