I don't think that solving these kinds of difficult problem is about thinking slowly.
Unfortunately for most engineers, their entire lives and schooling have never exposed them to the sorts of problems being discussed, namely, problems where there is insufficient information coupled with limited ability to gather more, or where some of the information you think you know is incorrect, or where you are misinterpreting the information you have, etc.
These kinds of problems require you to go over everything multiple times. Really consider what you actually know. Doubt yourself. Make educated assumptions. Squeeze everything you've observed dry, even the seemingly meaningless, random, or ordinary. And then you'll get a theory, that's hopefully testable, and you'll test it.
> problems where there is insufficient information coupled with limited ability to gather more, or where some of the information you think you know is incorrect, or where you are misinterpreting the information you have, etc.
What? These sorts of problem are very common in software engineering/development.
I don't think that solving these kinds of difficult problem is about thinking slowly.
Unfortunately for most engineers, their entire lives and schooling have never exposed them to the sorts of problems being discussed, namely, problems where there is insufficient information coupled with limited ability to gather more, or where some of the information you think you know is incorrect, or where you are misinterpreting the information you have, etc.
These kinds of problems require you to go over everything multiple times. Really consider what you actually know. Doubt yourself. Make educated assumptions. Squeeze everything you've observed dry, even the seemingly meaningless, random, or ordinary. And then you'll get a theory, that's hopefully testable, and you'll test it.
In many consulting projects, this is a regular Tuesday.
> problems where there is insufficient information coupled with limited ability to gather more, or where some of the information you think you know is incorrect, or where you are misinterpreting the information you have, etc.
What? These sorts of problem are very common in software engineering/development.
This is a correct (though shallow) take on two problem solving approaches which have been formally described for over a decade:
https://materiasiis.uson.mx/docs/control_de_calidad/1.CALIDA...
Notably, when the Lucky Guess method doesn't work, don't keep guessing, troubleshoot properly.