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).
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).