As many others have said, getting away from the keyboard, white board, design/requirement documents and doing something completly different is usually the surest way of acheiving breakthroughs when I get stuck when analysing a problem or coding the solution.

However, I noticed a long time ago that when the Eureka moments occur, that whatever else I am involved at the time usually has a non-obvious bearing upon the problem. The inspiration often comes from seeing or using a manual or natural mechanism that is in some way analogous to the problem I am trying to solve. Good examples are hard to describe, but a trivial one I remember was the first time I really understood the the bi-directional version of the bubble sort was when I de-shuffled a pack of playing cards in a pub to check they were all there. The pack was made up from bits of several different packs, so a simple count wasn't enough.

Since then, I have actively sought out non-computerised analogies to intractable problems. Sometimes I find something directly analogous and it helps by allowing me to observe the individual steps involved, but this is rare. More often, the link or analogy is considerably more tenuous. I once took inspiration for a date parsing routine designed to handle multiple input formats from a pin-ball machine. You know those sections where you have to knock down all of a set of pop ups in any order to get the bonus points. Originally, I tried to code (in C) a routine to look for each of the possible formats in each of the possible orders. The inspiration was to scan the string linearly, compare what I found against each of the bits I was looking for: Does it look like a year, if so, knock down the flag; does it look like a month, knock down the flag. If the flag is already down, I've got a problem. Are all the flags down, Im finished. This meant that in most cases, I made a single pass to find the date, rather than the multiple passes required by the "Is it in this format? Or this? Or this?".

In reality, I don't actually have to find an anology, the process of looking for the anology is often enough. The very act of looking at an unrelated process and trying to map it to the problem often has two beneficial side effects.

• It stops you thinking about the problem directly, whilst still keeping the problem in background.
• It has a tendancy to re-order your priorities and assumptions.

Traffic lights make a good analogy for bi-directional semaphores in multi-threaded and multi-process control.

The take-a-number queueing and priority system in post offices and deli-counters makes a good analogy for the 'pool' model of using threads and processes.

Take a look at the way the trunks, branches, twigs and stems of a tree grow to get a good insight into the working of the Mandlebrot sets.

Many of my flashes of inspiration come from looking for a good analogy, regardless of whether I find one or not. It helps if you have a good familiarity with an industry or field outside of computing I think. In my case, having worked in the auto industry, I find many anologies there that inspire solutions in my code, but I worked with guy a few years ago that found all sorts of inspired solutions in music, both the notations used and the order therein.

Try it next time you get stuck with your code, it might work for you too:)