Ha, I like this one! Actually these algorithms may approximate one another when generalized. Pirsig explores the philosophy more deeply, though; for example, generating a hypothesis: where does it come from, and is it possible to run out of hypotheses? Pirsig argues no, you practically can’t.
Although personally, I use a somewhat modified version:
1. Find the closest person who knows more about what you are doing than you do. Then, for everything you can say about the problem, do so, out loud. (It is very important that you say it out loud and not just in your head.)
There is a very good chance that you are the person who knows the most about the problem, at least in the way you are presently thinking about it. This implies that you need to speak out loud about the problem, to yourself, and nobody else if necessary. Therefore, in order to make yourself take this step seriously, record your dictated thoughts (even if you never plan to play them back). This is a very important 'hack', because it simultaneously tricks your brain into thinking somebody is listening, causing you to take what you say with utmost seriousness (even though it might start out as non-sense), while at the same time giving you the freedom to say whatever you want (which is almost never the case when somebody is actually listening, since mutual intelligibility is a prerequisite for all conversation).
2a. Draw what you see in your "mind's eye" when inspiration strikes (when with a colleague, at the board; alone, on a blank, unruled sheet of paper). Do this for months, until you become fluent in a private 'diagram language' for describing your thoughts.
Similarly, utilize a private 'jargon language' to name things that don't exist yet.
2b. Start typing it all into org-mode, until...
3. ...you realize what the actual solution is. Then go do that.
N.b.: If you squint, everything I just said is nothing more than a generalization of what professional mathematicians do at the blackboard. I learned to think this way in undergrad in the math program, but it's equally applicable to any field IMO.
Disclaimer: This technique risks making you hopeless impractical and obsessive until it starts to pay off. And I have to admit, this is not really an algorithm for solving problems, so much as coming up with creative insights about problems. I think that most problems don't need some massive insight so much as dogged persistence and organization (in which case you should completely disregard this post).
Does this strategy apply to programming? Consider the xkcd cartoon[0] that Bonooru posted upthread. One possible realization of what the the "?" step in that cartoon could be: utilize my "conceptual" strategy to shrink the amount of time spent doing actual coding to a minimum. Doing this with abandon is surely dangerous and risks getting stuck in the first, trivial loop, but if you can find a way to iterate on paper...
Mathematics is the part of physics where experiments are cheap. -Vladimir Arnold
...then perhaps, by analogy: the kind of conceptual work I'm promoting here is the part of programming where the "inner loops" (that is, actual coding, like in the xkcd cartoon) are empty. Take this too seriously, though, and you may one day wake up in academia[1]... :-)
1. Write down the problem.
2. Think real hard.
3. Write down the solution.