The Power of Intuition

What Hacker News says

1. shadowsun7Sep 2021
   I would recommend the series first — AE assumes familiarity with the recognition primed decision making model (or RPD) which I cover in the series.

   If you want to read books to prepare yourself, read:

   - Sources of Power by Gary Klein

   - Power of Intuition by Gary Klein

   Before AE.

   And then be prepared to download LOTS of papers to read concurrently while reading the book. AE is not written for the layperson.

   Show morethread
2. shadowsun7Jun 2020
   In Peak, Ericsson seems to finally settle on one definition, which was what I used in the end. He calls what you just describe "not being able to deliberately practice like a grandmaster" a completely different thing — purposeful practice.

   There's a whole chapter in Peak where he tries to talk about what to do if you are in a field with badly developed pedagogical methods. It's basically a badly written copy of The Power of Intuition (Klein). I was incredibly dissatisfied with it, because I was mostly interested in putting DP to practice, and his recommendations were far from practicable. I wish he had just referred to Hoffman or Klein, both of them practitioners in NDM, and therefore both more familiar with attempts to design training programs for fields where no pedagogical rigour exist.

   I know you're inclined to give Ericsson a pass, and pass things off as deliberate practice even when his definition clearly excludes said thing. But my view is that we should call a spade a spade and use the exact definitions the man used. If he thought it was good enough for his popular audience, it should be good enough for me.

   Show morethread
3. itamarstApr 2018
   This is a better articulation of where you feel stuck, so that's helpful.

   A lot of design decisions come down to pattern matching: you learn how to recognize certain patterns and that helps you decide (I recommend reading some of Gary Klein's books, e.g. "Power of Intuition"). So you need to expand patterns you can match.

   Some ideas:

   1. Read case studies, e.g. http://www.aosabook.org/en/index.html. But ideally case studies tied to specific problems you're facing at work, rather than generically. A case study is specifically "here's what we built and why", which is more useful for pattern matching than "here's a tool you can do some stuff with".

   2. Get your experienced colleagues to explain their thinking. Since they're mostly pattern matching, they can't necessarily offhand explain why they chose something, so maybe try to force them to think more explicitly. E.g. ask questions like "here's a hypothetical different approach, why wouldn't you go with that" and see if they can articulate that beyond "it's wrong" - how is it wrong?

   3. Switch to job where you can learn more.

   4. Build prototypes, see how they fail.

   5. Get your colleagues to tell stories about failures and successes.

   Show morethread
4. itamarstApr 2018
   Learning is a skill you can get better at, so it's just a dependency. Learning is not an unchangeable talent. Some books that will help you learn better:

   * Power of Intuition, about naturalistic decision making - https://www.amazon.com/Power-Intuition-Feelings-Better-Decis...

   * How Learning Works - https://www.amazon.com/How-Learning-Works-Research-Based-Pri... (my review: https://codewithoutrules.com/2016/03/19/how-learning-works/)

   No doubt others can recommend more books.

   Show morethread
5. itamarstJul 2017
   Oh, and, read Gary Klein's book Intuition at Work aka The Power of Intuition.
   thread
6. itamarstJun 2017
   An employee who dropped production on first day is not at fault, it's the company's fault. I have similar but not quite as bad story, deploying code that almost brought down our company's main customer. My fault, but organization was at fault too (but to be fair we had ops people who shut it off when it caused problems).

   So two thoughts:

   1. How bad the outcome is doesn't necessarily reflect on how big a mistake something is. Software is so complex that even small hard-to-avoid mistakes can cause big problems... and sometimes big mistakes only cause trivial problems. So while big mistakes make good stories (and I'm sure people will post some), every mistake is worth learning from.

   2. Most problems are, in the end, not an individual's fault. It's a whole system that failed. So don't just like for what you can do better, though that's important. Figure out where the system broke, and how to make the system better.

   If you want to more deliberately learn from mistakes, Gary Klein's book "The Power of Intuition" is really useful.

   (I am BTW writing a weekly email with mistakes I've made both programming and in my career - the story I mentioned above is the first email you'd get, and I just sent out the 41st, with plenty more mistakes to come. 20+ years of coding and still more mistakes to make! https://softwareclown.com if you're interested.)

   Show morethread