[js2]

Ah yes, just four steps:

1. Understand the problem.

2. Devise a plan.

3. Carry out the plan.

4. Look back.

---

Compare with the Fenyman Algorithm:

1. Write down the problem.

2. Think real hard.

3. Write down the solution.

https://wiki.c2.com/?FeynmanAlgorithm

(The discussion on FeynmanAlgorithm links back to Polya's book since not everyone is Feynman.)

[jiggawatts]

Reminds me of the official Microsoft guidance for big projects like migrating Exchange to the cloud, merging an Active Directory, or whatever.

They’re all verbatim the same, except for the product name.

1. Gather requirements.

2. Devise plan.

3. Run a proof of concept

4. Run production migration

…etc.

It’s about as helpful as someone telling you to “do your job”.

[keyle]

Classic:

    How to draw an owl:
    1. carefully darw a circle as the head of the owl
    2. draw the rest of the owl

[morkalork]

>Write down the problem

Sometimes this step is enough to get you 80% of the way to solving a problem.

[marginalia_nu]

The Feynman algorithm is very underrated. I think some people see it as a joke, as though it's clearly not a working method. But it's how I do most of my difficult work, possibly as a result of majoring in physics where "stare at the problem for a few hours" is the standard approach.

I think my strongest asset is not understanding when a problem is difficult and staring at the problem for hours anyway.

There are classes of problems that don't trivially decompose into a series of easier problems. The only way is to punch your way through them.

[bonoboTP]

Or his steps to do science:

1. Guess 2. Compute consequences 3. Compare with experiment - if they disagree, the guess was wrong.

https://www.youtube.com/watch?v=OL6-x0modwY

[jodrellblank]

You say 'ah yes' as if there's no value in these steps. Compare with more common steps:

1. Don't try to understand the problem, just stare at the given information blankly.

2. Instead of devising a plan or thinking real hard, try to "guess the teacher's password" and parrot any relevant sounding words for this ... or any related thing - https://www.lesswrong.com/posts/NMoLJuDJEms7Ku9XS/guessing-t... and the linked https://www.lesswrong.com/posts/48WeP7oTec3kBEada/two-more-t... - as if the universe will accept the words (map) as the solution (territory).

3. Carry out incantations handed down from above, regardless of whether they could be applicable to this problem; they are not understood which leaves room for them being potentially powerful and relevant.

4. Give up. If the incantations of power didn't help, what else is there to do? Don't look back.

Are these steps from How To Solve It in 1945 so different from Eric Raymond's "how to ask smart questions" from the 1990s(?) or from Eric Lippert's "How to debug small programs" from 2014 ( https://ericlippert.com/2014/03/05/how-to-debug-small-progra... )? His example "I wrote this program for my assignment and it doesn’t work." is still a common approach to "problem solving" nearly a decade later, not just for student coders either.

People seem to be missing:

- the belief that problems are solvable. (Instead apparently believing that some people know the answer or that the problem cannot be solved; not understanding that someone can start unknowing, work to solve, and then know).

- that solving something involves a mental model of how a thing works, in some context. (Instead apparently believing that solving is random or guesswork or luck or flash of inspiration, but not solved by any kind of knowable process).

- that solving something involves a feedback loop of gathering information, testing hypotheses, learning from the result, looking back (Instead trying one thing and stopping, not seeing if anything could be learned from the result, not trying to expand a mental model from what was known).

Even that this is a pet frustration of mine with some of my coworkers and internet programming askers, I still resist writing down the problem or thinking real hard (as far as I can do such a thing).