Why slow thinking wins(bostonglobe.com)
bostonglobe.com
Why slow thinking wins
https://www.bostonglobe.com/ideas/2015/07/25/the-power-slow-thinking/ToZbzYl7rG0yVMCtsZ7WnJ/story.html
18 comments
Curious: what domain do you work in? In mine (consumer webapps, and now consumer mobile), "never shipped a bug" is a meaningless phrase, because "a bug" depends on how millions of consumers respond to it, and very often code that is deliberately buggy from a technical POV (dropping data on the floor, for example) actually ends up with better metrics.
I used to work in financial software, where things were very different, and before that I'd interned at a company that did avionics software, which is a whole other ballgame. I just find it interesting that the definition of "bug" can vary so greatly across domains in what's commonly thought of as a single industry.
I used to work in financial software, where things were very different, and before that I'd interned at a company that did avionics software, which is a whole other ballgame. I just find it interesting that the definition of "bug" can vary so greatly across domains in what's commonly thought of as a single industry.
For the term to be meaningful, 'bug' needs to be more tightly defined - a discrepancy between the specification (both as stated and intended[1]) and the actual behaviour of the code is a bug. Now, if the wrong behaviour is actually beneficial, then there's nothing wrong with changing the spec, that's basically the central idea in agile - but the idea that if given a spec to make the blue button green, you make the button green - and if users then react negatively to that, then that doesn't mean you shipped a bug in any meaningful sense. It also doesn't mean you shouldn't change it back, quickly, but the developer did not ship a ship.
1: Just because the specification doesn't specifically state "shouldn't crash if the user inputs a negative number", it's understood that the program shouldn't crash given any user input.
1: Just because the specification doesn't specifically state "shouldn't crash if the user inputs a negative number", it's understood that the program shouldn't crash given any user input.
We were working on a compiler for a language developed in-house.
I agree -- different kinds of programming impose very different demands.
I agree -- different kinds of programming impose very different demands.
I'm young so this may get better with time but I've had a hard time finding environments that support the slower style. It's often derided as being the "waterfall" method.
"slower" and "waterfall" are orthogonal.
Waterfall is a theoretical idea that sounds nice, but fails miserably in practice - the key problem being the assumption that if you are diligent enough at collecting the requirements and constraints, you can resolve them at the design and implementation stage. The reality is that there is never enough time/information/budget/knowledge/resources to map the requirements and constraints, and furthermore, those change all the time so even in the unlikely case that you have managed to map the territory, by the time you deliver the solution, the territory has changed.
One can argue theoretically for waterfall as much as they want (and in fact some people do), but the collective experience with waterfall is so abysmal that whoever wants to waterfall needs to argue against the failures, rather than for the method.
Waterfall is a theoretical idea that sounds nice, but fails miserably in practice - the key problem being the assumption that if you are diligent enough at collecting the requirements and constraints, you can resolve them at the design and implementation stage. The reality is that there is never enough time/information/budget/knowledge/resources to map the requirements and constraints, and furthermore, those change all the time so even in the unlikely case that you have managed to map the territory, by the time you deliver the solution, the territory has changed.
One can argue theoretically for waterfall as much as they want (and in fact some people do), but the collective experience with waterfall is so abysmal that whoever wants to waterfall needs to argue against the failures, rather than for the method.
I think more large scale projects have succeeded using waterfall than Agile.
I'm not aware of any large scale projects that were attempted using Agile. Are you? FWIW, I don't think Agile is the answer - there's a continuum between (and beyond) waterfall and agile, and it's not one-method-fits-all anyway.
For that matter, I can hardly think of large scale software projects that succeeded in the sense that they were on time, on budget, and satisfied the requirements a-posteriori, regardless of methodology.
Regardless, how many projects that people here are involved in are really large scale ?
For that matter, I can hardly think of large scale software projects that succeeded in the sense that they were on time, on budget, and satisfied the requirements a-posteriori, regardless of methodology.
Regardless, how many projects that people here are involved in are really large scale ?
I'm not defending agile, but what is described in the abstract cannot fit with what I am familiar with as "agile" - an almost defining quality of an agile process (as I was introduced to it) is that at any given moment, the status of the project is transparent and well known by all stakeholders. Thus, if you discover all of a sudden that the project is late and over budget, you have been sleeping at the wheel.
(Note: This is not a "no true scottsman" argument. And I honestly think agile is only a good match for some projects, and not e.g. infrastructure. Nevertheless, this does not sound like the "agile" I know).
(Note: This is not a "no true scottsman" argument. And I honestly think agile is only a good match for some projects, and not e.g. infrastructure. Nevertheless, this does not sound like the "agile" I know).
Hello from a dev manager in a big enterprise! My personal experience after working in an org where the PMO tried to force waterfall and the devs tried to force "agile" is that the key to success has nothing to do with project management methodology and everything to do with 1) interpersonal relationships, and 2) the technical team having adequate domain knowledge to make good decisions while planning and executing on the project/product. Lack of #2 is why many corporations force waterfall -- because they can't or don't trust the dev teams to make intelligent choices, and/or because the business stakeholders can't be bothered to engage with them on a daily basis. It's pure laziness and lack of respect for the software that drives processes.
I'm going to chime in that "slower" and "waterfall" are also orthogonal, but discuss it from a completely different point (hence not replying to that comment).
Agile, done right, -can- (and I'd argue, -should-) be slow, in the context of what this is talking about. 'Slow' doesn't mean delaying working on coding until all requirements are defined (i.e., waterfall), it means once you start working, to make sure you've thought about it, to make sure you're careful in your implementation, that you pause and think about what you're doing, don't just breeze over edge cases or possible error conditions.
You can think slow or act fast even given one requirement. Say I have a requirement, "I need a REST endpoint that gives me X information".
The fast approach is to just say "Okay, this is getting information; that's a GET. We've already been writing this in this language and framework, let me just stick a new endpoint in the router file that gets that info and returns it".
The slow approach is to say all of that, and then follow it with "Okay. What happens if this information isn't there? Can that happen? If something goes wrong, do I need to return a sensible error message along with the HTTP error code? Does the consumer understand a specific kind of error message, such that it will be displayed to the user? As part of getting X, are there any additional parameters that we need; i.e., is it enough to get -all- Xs for the call, or is the size of it likely to be enough to warrant getting just Xs that match (filtering criteria)? Does the DB need to be optimized for that sort of query?" Note that agile -does- mean you probably don't address all of those as part of this story; KISS, YAGNI, etc, still apply. But taking it slow means you -think- about those things.
What's the difference, if it doesn't lead to any change? Well, thinking about it means you likely cause any failures to fail gracefully, in a well defined, recognizable, predictable manner. It also likely means you've brought up those issues, and you can determine whether they should be tackled at all; you might be able to do them as part of this story if they're small, or add some hooks such that it'll be easy to add them later, but it might also lead to creating new stories, that get prioritized into the next sprint.
Now, while people argue you need to move fast and break things sometimes, I'd argue that taking things 'slow' like that -is always better-. Why? Because if you take things slow, you can still choose not to do something. The overhead of just thinking about it, and then actively choosing to take the fastest path, is very, very small compared to just rushing in to do the fastest path. Maybe 10% extra or so. But as often as not, taking it slow will lead to you coming up with additional work that you really need to do; without it your app will fall over, or your users will get pissed off, or whatever. While that then feels slower (you are, after all, doing more), it's getting things done that -need to be done-. If you'd taken the fast approach, you'd realize you need them later, but in hindsight would justify moving fast because "well, we didn't know that then, and we got features out the door". Sure, you didn't know that then because you -didn't pause to think about it-. You can't claim that you couldn't have predicted it, and moved to avoid it, because you never tried to predict it. If you -did- spend some time thinking, and fail to catch something, then you really couldn't have predicted it, because you -tried- to. You've optimized for the best possible path as you can understand it at the time; taking the fastest path may or may not land you there, and you can't know whether it was optimal.
In short, moving fast means defaulting to not doing the extra work; moving slow means thinking, and actively -deciding- what level of work needs to be done. You can be nearly as fast as 'moving fast' (by thinking about it and deciding you don't want to do the extra stuff), but you can also decide that certain tasks really need to be done, and that, while making you slower, leads to a better product.
Agile, done right, -can- (and I'd argue, -should-) be slow, in the context of what this is talking about. 'Slow' doesn't mean delaying working on coding until all requirements are defined (i.e., waterfall), it means once you start working, to make sure you've thought about it, to make sure you're careful in your implementation, that you pause and think about what you're doing, don't just breeze over edge cases or possible error conditions.
You can think slow or act fast even given one requirement. Say I have a requirement, "I need a REST endpoint that gives me X information".
The fast approach is to just say "Okay, this is getting information; that's a GET. We've already been writing this in this language and framework, let me just stick a new endpoint in the router file that gets that info and returns it".
The slow approach is to say all of that, and then follow it with "Okay. What happens if this information isn't there? Can that happen? If something goes wrong, do I need to return a sensible error message along with the HTTP error code? Does the consumer understand a specific kind of error message, such that it will be displayed to the user? As part of getting X, are there any additional parameters that we need; i.e., is it enough to get -all- Xs for the call, or is the size of it likely to be enough to warrant getting just Xs that match (filtering criteria)? Does the DB need to be optimized for that sort of query?" Note that agile -does- mean you probably don't address all of those as part of this story; KISS, YAGNI, etc, still apply. But taking it slow means you -think- about those things.
What's the difference, if it doesn't lead to any change? Well, thinking about it means you likely cause any failures to fail gracefully, in a well defined, recognizable, predictable manner. It also likely means you've brought up those issues, and you can determine whether they should be tackled at all; you might be able to do them as part of this story if they're small, or add some hooks such that it'll be easy to add them later, but it might also lead to creating new stories, that get prioritized into the next sprint.
Now, while people argue you need to move fast and break things sometimes, I'd argue that taking things 'slow' like that -is always better-. Why? Because if you take things slow, you can still choose not to do something. The overhead of just thinking about it, and then actively choosing to take the fastest path, is very, very small compared to just rushing in to do the fastest path. Maybe 10% extra or so. But as often as not, taking it slow will lead to you coming up with additional work that you really need to do; without it your app will fall over, or your users will get pissed off, or whatever. While that then feels slower (you are, after all, doing more), it's getting things done that -need to be done-. If you'd taken the fast approach, you'd realize you need them later, but in hindsight would justify moving fast because "well, we didn't know that then, and we got features out the door". Sure, you didn't know that then because you -didn't pause to think about it-. You can't claim that you couldn't have predicted it, and moved to avoid it, because you never tried to predict it. If you -did- spend some time thinking, and fail to catch something, then you really couldn't have predicted it, because you -tried- to. You've optimized for the best possible path as you can understand it at the time; taking the fastest path may or may not land you there, and you can't know whether it was optimal.
In short, moving fast means defaulting to not doing the extra work; moving slow means thinking, and actively -deciding- what level of work needs to be done. You can be nearly as fast as 'moving fast' (by thinking about it and deciding you don't want to do the extra stuff), but you can also decide that certain tasks really need to be done, and that, while making you slower, leads to a better product.
I suspect it's also a matter of knowing when to use what speed. That, apparently, takes a while to learn.
And it's "no bug was found that anyone knew of". Not a bad standard, but latent defects frequently have a long shelf life.
And it's "no bug was found that anyone knew of". Not a bad standard, but latent defects frequently have a long shelf life.
> latent defects frequently have a long shelf life
They do, but it has also been observed that code in which no bugs have been found is less likely to harbor them than code in which some bugs have already been found and fixed (other things being equal, of course).
If I had had to bet where in the whole codebase the next bug would turn up, I certainly would not have bet it would be in this guy's code.
They do, but it has also been observed that code in which no bugs have been found is less likely to harbor them than code in which some bugs have already been found and fixed (other things being equal, of course).
If I had had to bet where in the whole codebase the next bug would turn up, I certainly would not have bet it would be in this guy's code.
Daniel Kahneman's and Gary Klein's (two of the experts usually seen on opposing sides of the conversation) article "A Failure to Disagree" is worth a read [1]:
"This article reports on an effort to explore the differences between two approaches to intuition and expertise that are often viewed as conflicting: heuristics and biases (HB) and naturalistic decision making (NDM). Starting from the obvious fact that professional intuition is sometimes marvelous and sometimes flawed, the authors attempt to map the boundary conditions that separate true intuitive skill from overconfident and biased impressions. They conclude that evaluating the likely quality of an intuitive judgment requires an assessment of the predictability of the environment in which the judgment is made and of the individual’s opportunity to learn the regularities of that environment. Subjective experience is not a reliable indicator of judgment accuracy."
They agree on almost every point, they disagree on the usefulness of checklists on low-validity environments and on "whether there’s more to be gained by listening to intuitions or by stifling them until you have a chance to get all the information." [2]
[1] 2009, Conditions for intuitive expertise: a failure to disagree., Kahneman, Klein. http://www.fiddlemath.net/stuff/conditions-for-intuitive-exp... [2] Strategic decisions: When can you trust your gut? http://www.mckinsey.com/insights/strategy/strategic_decision...
"This article reports on an effort to explore the differences between two approaches to intuition and expertise that are often viewed as conflicting: heuristics and biases (HB) and naturalistic decision making (NDM). Starting from the obvious fact that professional intuition is sometimes marvelous and sometimes flawed, the authors attempt to map the boundary conditions that separate true intuitive skill from overconfident and biased impressions. They conclude that evaluating the likely quality of an intuitive judgment requires an assessment of the predictability of the environment in which the judgment is made and of the individual’s opportunity to learn the regularities of that environment. Subjective experience is not a reliable indicator of judgment accuracy."
They agree on almost every point, they disagree on the usefulness of checklists on low-validity environments and on "whether there’s more to be gained by listening to intuitions or by stifling them until you have a chance to get all the information." [2]
[1] 2009, Conditions for intuitive expertise: a failure to disagree., Kahneman, Klein. http://www.fiddlemath.net/stuff/conditions-for-intuitive-exp... [2] Strategic decisions: When can you trust your gut? http://www.mckinsey.com/insights/strategy/strategic_decision...
I've worked with beginning programmers before and one of the characteristics I see with the most struggling ones is that they have a tendency to repeatedly make small, almost random changes to code and run it until they get something which seems to work. Their code looks like a mess and almost always fails edge cases - when questioned on the behaviour of their solution on such, they often have no idea what it'll do, and only vaguely understand the code they wrote. I wonder if this is an example of them using the "fast thinking" path almost exclusively.
I've had success with forcing them to use pencil and paper, or a whiteboard, to design their algorithm and writing the code, before ever touching a computer to test it. This is a way to force them into the "slow thinking" mode, because there is no immediate feedback and they'll have to think more carefully about it. Put them in front of an IDE, however, and they just get tempted into writing code without thinking much about what it's doing.
I've had success with forcing them to use pencil and paper, or a whiteboard, to design their algorithm and writing the code, before ever touching a computer to test it. This is a way to force them into the "slow thinking" mode, because there is no immediate feedback and they'll have to think more carefully about it. Put them in front of an IDE, however, and they just get tempted into writing code without thinking much about what it's doing.
Perhaps I'm just begging to be flamed, but I've noticed this quite a bit with TDD. It's easy to write a test case, jiggle around the code until it works, and then call it "ready".
In an ideal world, the jiggling around would be followed by a review of the relevant codebase and a good refactoring, but this step is pretty universally missed in my experience. Additionally, the thinking should be occurring in the "build the tests" phase, but it's not. Or rather, only the "happy path" tests are built; the corner cases and error cases are missed or outright skipped.
I noticed this in myself first, and slowing down has definitely helped. As has spelling out the test cases before touching any code.
In an ideal world, the jiggling around would be followed by a review of the relevant codebase and a good refactoring, but this step is pretty universally missed in my experience. Additionally, the thinking should be occurring in the "build the tests" phase, but it's not. Or rather, only the "happy path" tests are built; the corner cases and error cases are missed or outright skipped.
I noticed this in myself first, and slowing down has definitely helped. As has spelling out the test cases before touching any code.
I've hit this. Usually it's because I originally thought about it, created a generic solution to my understanding of the code/domain, hit an edge case, tweak it to handle that edge case, hit another edge case/break a test, tweak it to handle both that and the original, repeat.
I think everyone hits this; to avoid it you have to have a perfect understanding of the domain a priori. The difference I see now, compared to when I was starting out, is I recognize I'm doing it more quickly. Once I do, I will re-examine the domain from the perspective of "it includes all these edge cases", and generate a new abstraction that encompasses more (hopefully all) of them.
I think everyone hits this; to avoid it you have to have a perfect understanding of the domain a priori. The difference I see now, compared to when I was starting out, is I recognize I'm doing it more quickly. Once I do, I will re-examine the domain from the perspective of "it includes all these edge cases", and generate a new abstraction that encompasses more (hopefully all) of them.
I refer to the former as "now I will jiggle things randomly until they unbreak". (source credit to Linus T)
Everyone remembers the story of the tortoise and the hare, but no one seems to have learned the lesson it teaches:
Uh, no. I'm pretty sure everyone learned the apparent lesson that "slow-and-steady wins the race". Of course, that lesson is seriously incorrect since almost every race is won by the fastest. The real lesson is that pride goes before a fall. That is not what the article is suggesting.
Daniel Kahneman, the only non-economist to be awarded the Nobel Prize in economics.
Uh, no. John Nash, the only economics "Nobel prize" winner most people could actually name, is also not an economist.
And then the article goes on to suggest that brain teasers and their ability to tease brains--even MIT brains--have real-world implications. Okay, whatever.
Uh, no. I'm pretty sure everyone learned the apparent lesson that "slow-and-steady wins the race". Of course, that lesson is seriously incorrect since almost every race is won by the fastest. The real lesson is that pride goes before a fall. That is not what the article is suggesting.
Daniel Kahneman, the only non-economist to be awarded the Nobel Prize in economics.
Uh, no. John Nash, the only economics "Nobel prize" winner most people could actually name, is also not an economist.
And then the article goes on to suggest that brain teasers and their ability to tease brains--even MIT brains--have real-world implications. Okay, whatever.
3 interesting/fun word problems from TFA:
1) A bat and a ball cost $1.10. The bat costs $1.00 more than the ball. How much does the ball cost? ____cents
2) If it takes five machines five minutes to make five widgets, how long would it take 100 machines to make 100 widgets? ____minutes
3) In a lake, there is a patch of lily pads. Every day, the patch doubles in size. If it takes 48 days for the patch to cover the entire lake, how long would it take for the patch to cover half of the lake? ____days
How did you do? (see article for answers)
1) A bat and a ball cost $1.10. The bat costs $1.00 more than the ball. How much does the ball cost? ____cents
2) If it takes five machines five minutes to make five widgets, how long would it take 100 machines to make 100 widgets? ____minutes
3) In a lake, there is a patch of lily pads. Every day, the patch doubles in size. If it takes 48 days for the patch to cover the entire lake, how long would it take for the patch to cover half of the lake? ____days
How did you do? (see article for answers)
Got all three, but I'm a massive outlier on these things (statistician and developer, with a keen interest in physics), so they're questions that match patterns for the "you need to think about this" trigger in my head.
I find I fall over far more on things that hit that trigger needlessly, rather than the other way around (problems that look like I need to think about, but where the intuitive result is the correct one).
All things considered, I'd rather have the problem that way around and over-think and lose time needlessly than get the wrong answer more often. However, I'm biased to wanting that to be the best way, so I'm unreliable as to saying to what degree it's a "better" way to think.
I find I fall over far more on things that hit that trigger needlessly, rather than the other way around (problems that look like I need to think about, but where the intuitive result is the correct one).
All things considered, I'd rather have the problem that way around and over-think and lose time needlessly than get the wrong answer more often. However, I'm biased to wanting that to be the best way, so I'm unreliable as to saying to what degree it's a "better" way to think.
I have to wonder if #3 isn't a quick thinking/pattern match for people with a CS background. Instant trigger/right for me. I'd think that people who work algorithmically should do better than a control group.
I'm defensive with that statement because there's quite a few "people studying the subject do no better than the average" experiments (in economic) but I think there's a difference between academic knowledge and applied knowledge so if you think about complexity problems often you should do better on this one.
The interesting takeaway for me is that environment probably matters. If I take a test like this in a very relaxed environment I'm probably slowing down automatically.
The interesting takeaway for me is that environment probably matters. If I take a test like this in a very relaxed environment I'm probably slowing down automatically.
All three of them were a pattern match for me. The first one was an obvious "Subtract the difference, split the remainder" problem. The second one I immediately thought "What's the rate?", did a little math, and figured out that in both cases one machine builds one widget, so it'll still be 5 min/widget. The third one is a classic exponential growth problem.
I suspect that they are a lot easier when you are primed with the idea that they are trick questions.
Probably yes, but the point is that if you've seen similar problems before, the fact that they are counterintuitive trick questions is part of your pattern-match, and so you jump to a problem-solving strategy that manipulates the data you're provided in a way that's accurate rather than one that's not.
It's the same way you build expertise in any domain: proceed with your initial hypothesis, but then once experience proves you wrong, build a new, more accurate mental model. That new model will give right answers in a greater percentage of cases, but inevitably it's wrong too, and so you repeat the process.
It's the same way you build expertise in any domain: proceed with your initial hypothesis, but then once experience proves you wrong, build a new, more accurate mental model. That new model will give right answers in a greater percentage of cases, but inevitably it's wrong too, and so you repeat the process.
Agree about #3. On reading "doubles" my brain went "2^x" by reflex.
Those were fun.
I quickly came up with the incorrect answers for #1 and #2, but was able to realize that something was wrong with them and thought about it for a few more seconds and got the right answers.
I had the right answer with "fast" thinking for #3 though.
Note: When I say quickly & fast, I mean in less than a second, just the impulse answer. That is what fast thinking is I believe, but correct me if I am wrong.
I quickly came up with the incorrect answers for #1 and #2, but was able to realize that something was wrong with them and thought about it for a few more seconds and got the right answers.
I had the right answer with "fast" thinking for #3 though.
Note: When I say quickly & fast, I mean in less than a second, just the impulse answer. That is what fast thinking is I believe, but correct me if I am wrong.
These fast thinking problems rely on pattern recognition, so they will be easy if you have already seen the pattern, but you will fail if you apply the wrong pattern. Problem 3 tricks people who are used to everything being linear, which would probably be rather few people on HN.
I think the important skill is to be on the lookout, in your fast thinking, for problems which are slightly off. This is a clue that the pattern doesn't fit, and you should revert to slow thinking.
I think the important skill is to be on the lookout, in your fast thinking, for problems which are slightly off. This is a clue that the pattern doesn't fit, and you should revert to slow thinking.
Am I the only one that got tripped up by the wording of the second question? My immediate thought was, "Does that mean five minutes EACH or five minutes TOTAL?"
Without a clear question, my brain refused to give an answer, so I got it wrong. It annoys me that it is presented without enough information and then you're told, "Your intuition is not as good as you think it is."
1 and 3 were fun though.
Without a clear question, my brain refused to give an answer, so I got it wrong. It annoys me that it is presented without enough information and then you're told, "Your intuition is not as good as you think it is."
1 and 3 were fun though.
Interesting and fun? Not for me; all three are decades old and very well-known (the answer to the first jumped out the moment I read $1.10, possibly earlier; for the third, I scanned ahead to the 48). I would think any 10 year old with a knack for puzzles would know of these. If not, kids surely have changed over time. Maybe those PCs and iPads provide superior distractions?
1. The impulse to say 10 cents was there, but solving the equation led to the right answer.
2. Got this right in a few moments by thinking about it (no math).
3. Instantly knew the answer thanks to having watched "the most important video you'll ever see": https://www.youtube.com/watch?v=F-QA2rkpBSY
2. Got this right in a few moments by thinking about it (no math).
3. Instantly knew the answer thanks to having watched "the most important video you'll ever see": https://www.youtube.com/watch?v=F-QA2rkpBSY
This advice seems to be in stark contrast to the "speed as a habit" thread that everyone got excited about: https://news.ycombinator.com/item?id=9923239
Speed as a habit seems like it would ruin the ability to slow-think. Is there a dichotomy here or can we do both?
Speed as a habit seems like it would ruin the ability to slow-think. Is there a dichotomy here or can we do both?
You can do both and in fact they complement each other. Doing things fast allows you to do more iterations of experimenting/thinking, before you commit to your final solution. If you work slowly, you usually have to rely on your first intuition, because you don't have time for anything else. If you work fast, you can do more work up front, evaluate more options, test for more edge cases, etc. It helps you get a better picture of the problem you are trying to solve and that is what the "slow thinking" is about.
It seems that way, but I think they are talking about two different types of speed.
"slow" thinking requires checking your immediate gut reaction and taking a moment to think through the problem.
"fast" decision making requires taking a moment to think about how much time it is really worth to make a decision.
Arguably making "fast" decisions requires thinking "slow" about the length of time you should spend making the decision.
"slow" thinking requires checking your immediate gut reaction and taking a moment to think through the problem.
"fast" decision making requires taking a moment to think about how much time it is really worth to make a decision.
Arguably making "fast" decisions requires thinking "slow" about the length of time you should spend making the decision.
I think not.
If you have the impulse to go fast, think about prototyping whatever it is you are trying to do, if you can. You should agree with yourself to dispose of the prototype completely. By the time you've gone through debugging the prototype you'll know much of what is needed to do the real thing.
Obviously, this doesn't always work. In those cases, whiteboards, pen and paper, even a text document can help.
If you have the impulse to go fast, think about prototyping whatever it is you are trying to do, if you can. You should agree with yourself to dispose of the prototype completely. By the time you've gone through debugging the prototype you'll know much of what is needed to do the real thing.
Obviously, this doesn't always work. In those cases, whiteboards, pen and paper, even a text document can help.
I don't think those things are at odds. To be fast habitually you have had to slow down to pave the pathways for speed. What most organizations miss out on is thinking they can go fast without paving the way first. In all disciplines the fundamentals never come cheap or fast but once they are there then you can go as fast as you want and you can do it confidently.
Shouts out to A.E. for riding in that 6-0
Move fast, stick slow, think fast, talk slow
Copying my reply from that thread:
Speed is important. Patience is important. Stepping back and smelling the flowers is important. It's not about fast or slow. It's about right, and you can't be right all the time if you're stuck in the habit of zooming along all the time.
I remember how many _years_ it took Apple to figure out how to do right-click properly while their competitors were speeding along with that silly second button.
Speed is important. Patience is important. Stepping back and smelling the flowers is important. It's not about fast or slow. It's about right, and you can't be right all the time if you're stuck in the habit of zooming along all the time.
I remember how many _years_ it took Apple to figure out how to do right-click properly while their competitors were speeding along with that silly second button.
I honestly didn't realize that Apple ever figured that out. I started out on Macs (Mac+), but haven't had one since the '90s. I used one earlier this year trying to do stuff for my cousin on her machine. That mouse was truly bizarre. You'd accidentally touch it a certain way and weird shit would happen.
I'm sure it's great once you learn it and get used to it, but not exactly intuitive.
I'm sure it's great once you learn it and get used to it, but not exactly intuitive.
I high school I went to extra lessons in physics. The teacher gave out a problem that he said it had a simple end result but he never seen an elegant way to solve it. An other guy the next class solved it with one really well designed figure and like three line of simple equations, it was awesome. I know he was a slow thinker, he wasn't really good at timed competitions However there was a competition where you had to solve problems from a journal monthly and send them back, he was really good at it.
First time I came across this idea was in Ed DeBono's "DeBono's Thinking Course" which (paraphrasing) said "the sheer physical speed of the clever mind leads it to find an immediate solution. But not necessarily the correct, or best solution." The book is full of excellent methods of improving thinking, and I believe he's put out a few other books since then.
I really like his "thinking hats" book. Seems a bit gimmicky but I really enjoy applying it every now and then. I even got colored baseball hats for it :D
>> Daniel Kahneman, the only non-economist to be awarded the Nobel Prize in economics
John Nash (mathematician) also won the econ Nobel
John Nash (mathematician) also won the econ Nobel
As did Kenneth Arrow[0], Merton&Scholes[1] (Fisher Black had already died at that point, and they don't award it posthumously), and Aumann[2].
These three are off the top of my head, I'm sure there are others as well. Also, it's not a real Nobel[3] - it's a later addition (although it is awarded by the same committee at the same ceremony).
[0] https://en.wikipedia.org/wiki/Kenneth_Arrow
[1] http://www.nobelprize.org/nobel_prizes/economic-sciences/lau...
[2] https://en.wikipedia.org/wiki/Robert_Aumann
[3] https://en.wikipedia.org/wiki/Nobel_Memorial_Prize_in_Econom...
These three are off the top of my head, I'm sure there are others as well. Also, it's not a real Nobel[3] - it's a later addition (although it is awarded by the same committee at the same ceremony).
[0] https://en.wikipedia.org/wiki/Kenneth_Arrow
[1] http://www.nobelprize.org/nobel_prizes/economic-sciences/lau...
[2] https://en.wikipedia.org/wiki/Robert_Aumann
[3] https://en.wikipedia.org/wiki/Nobel_Memorial_Prize_in_Econom...
It's funny how even after reading the answer to the bat-ball question months ago and forgetting it, I got it wrong again. I even took some time to think.
How can we make slow thinking less forgetful?
How can we make slow thinking less forgetful?
I've thought about this often and the only solution I can come up with is to disallow myself to think quickly when solving problems, even when I believe that I should reliably be able to do so[0].
I've noticed that when I take the time to think slowly through problems, although the initial activation energy is higher, that I end up saving time in the long run. Also, I tend to end up with a higher percentage of correct answers. This trend tends to increase with the complexity of the problem.
Yes, you probably lose some time on the easy problems, but I look at it as a method of gaining net time over days, weeks, etc.
This, unfortunately, is tough to stick with. It's tempting to skip the easy steps along the way (and let our System 1 do all the work, leaving System 2 to collect dust).
[0] - This is still a working hypothesis that I will undoubtedly go back and forth on for the years to come.
I've noticed that when I take the time to think slowly through problems, although the initial activation energy is higher, that I end up saving time in the long run. Also, I tend to end up with a higher percentage of correct answers. This trend tends to increase with the complexity of the problem.
Yes, you probably lose some time on the easy problems, but I look at it as a method of gaining net time over days, weeks, etc.
This, unfortunately, is tough to stick with. It's tempting to skip the easy steps along the way (and let our System 1 do all the work, leaving System 2 to collect dust).
[0] - This is still a working hypothesis that I will undoubtedly go back and forth on for the years to come.
At least for those problems, I don't think it's about trying to slow down. It's about trying to poke holes in your answer and make sure it holds up to some testing.
The intuitive answer to the first problem is $.10 but if you take time to double check and add a dollar to that, you see it's wrong.
I don't think this is too different from programming... the time you take to re-read some code you just wrote and think like a compiler and mentally execute the edge cases, etc.
The intuitive answer to the first problem is $.10 but if you take time to double check and add a dollar to that, you see it's wrong.
I don't think this is too different from programming... the time you take to re-read some code you just wrote and think like a compiler and mentally execute the edge cases, etc.
For me it was a case of reading the question properly, rather than skimming it and assuming you knew what it was asking.
I just wish we'd learn to appreciate this in the software/startup world and stop expecting people to come up with code/answers as quickly as possible. This is exactly why whiteboard coding is so bad of an interview metric.
With math questions, just keep practicing slow thinking to solve the problems. You know a shortcut formula to solve something? Don't use it, do it the long way. That will help you understand the nature of the problem, and most importantly, remember the fundamentals so you can easily recall them when needed.
A habit to work on is to make it a rule to verify your solutions, and especially the "fast" ones.
It's ok to do "fast thinking" if you verify, and go back and think through it properly if you fail (and hopefully over time learn to recognise what type of problems you know well enough for them to be worth making a "fast" attempt at first vs the ones you should just think through slowly from the outset.
It's ok to do "fast thinking" if you verify, and go back and think through it properly if you fail (and hopefully over time learn to recognise what type of problems you know well enough for them to be worth making a "fast" attempt at first vs the ones you should just think through slowly from the outset.
Because fast thinking isn't really thinking.
> Odeh has watched this idea transform his students’ behavior over the course of the school year: “I’ve seen students in the program in the hallway pulling their fellow students away from the start of a fight, just repeating and reminding them, ‘Warrior energy, warrior energy.’ ”
This was the most significant bit for me. Getting their thinking and behavioral pattern to change and creating a social enforcement around it. Inarguably, this is what school should be about; because so many kids do not get the right kind of nurturing they need at home, and lead destructive broken lives as a result, only perpetuating things further in their own children, and so on.
This was the most significant bit for me. Getting their thinking and behavioral pattern to change and creating a social enforcement around it. Inarguably, this is what school should be about; because so many kids do not get the right kind of nurturing they need at home, and lead destructive broken lives as a result, only perpetuating things further in their own children, and so on.
I would call it "thoroughly thinking" and "ignorant thinking" instead of fast and slow.
... then you would miss the core concept of Kahneman's thesis.
His book is very thorough in defining these systems, how they interact, and what situations each are a good fit for.
Fast thinking is important for low cost, instantaneous decisions. It's important so that your type 2 system isn't engaged all day, because that system consumes more energy and takes more effort to kick in.
The problem is that erroneous heuristics are frequently encoded in type 1. That doesn't mean it's useless -- there is an intuitive expertise that can be developed by correctly providing feedback to your type 1.
Try not to think of it like "good" versus "bad" thinking. Type I is incredibly powerful, but has all these gotchas.
The way I think of it is type 1 is like an associative or probabilistic cache. Lookups aren't always perfect -- sometimes type 1 answers an easier question rather than the one it asked -- but the idea is that you wouldn't be able to function if every single decision or interpretation had to be run through type 2.
In other words, type 1 is a shortcut to prevent your type 2 from being overloaded.
His book is very thorough in defining these systems, how they interact, and what situations each are a good fit for.
Fast thinking is important for low cost, instantaneous decisions. It's important so that your type 2 system isn't engaged all day, because that system consumes more energy and takes more effort to kick in.
The problem is that erroneous heuristics are frequently encoded in type 1. That doesn't mean it's useless -- there is an intuitive expertise that can be developed by correctly providing feedback to your type 1.
Try not to think of it like "good" versus "bad" thinking. Type I is incredibly powerful, but has all these gotchas.
The way I think of it is type 1 is like an associative or probabilistic cache. Lookups aren't always perfect -- sometimes type 1 answers an easier question rather than the one it asked -- but the idea is that you wouldn't be able to function if every single decision or interpretation had to be run through type 2.
In other words, type 1 is a shortcut to prevent your type 2 from being overloaded.
If you only ever read one of my HN posts, I recommend reading this one (because reading the book quoted in the article - "Thinking, Fast and Slow" - has changed my views on decision making and the human brain).
Good things take time.
The race towards performance doesn't really exist in nature, it's mostly made up, and only works well for sport entertainments. There really exists a culture of performance which is silly.
The race towards performance doesn't really exist in nature, it's mostly made up, and only works well for sport entertainments. There really exists a culture of performance which is silly.
It's not so much slow thinking as deliberate thinking, and forcing oneself to consider problems from more than one angle, eliminating ego from the solution. Pretty Platonic, if you ask me.
So how does one train in slow thinking?
One part is mentioned in the article. You need to be aware of your automatic reactions to various situations. Don't be satisfied with the first solution that comes to your mind. There might be things you have missed or your impulses are just wrong.
In programming, I think of myself as a slow thinker, but quite fast programmer. I very often find myself writing some code, re-reading it and throwing it away, because I realized it doesn't really work the way it should work. I do the same things with emails. Whenever I write a long email, the first version is most likely going to be discarded, but it still helps me organize my thoughts.
When solving a problem, always make sure you understand the root cause of it. Don't be satisfied with fixing the symptoms. If things don't work as you expect, make sure you completely understand why it is so.
Eventually, it becomes a habit to think twice before committing to something. You might still experiment, draw things on a whiteboard, do whatever helps you think, but you should not consider the side-products of that process to be the result.
In programming, I think of myself as a slow thinker, but quite fast programmer. I very often find myself writing some code, re-reading it and throwing it away, because I realized it doesn't really work the way it should work. I do the same things with emails. Whenever I write a long email, the first version is most likely going to be discarded, but it still helps me organize my thoughts.
When solving a problem, always make sure you understand the root cause of it. Don't be satisfied with fixing the symptoms. If things don't work as you expect, make sure you completely understand why it is so.
Eventually, it becomes a habit to think twice before committing to something. You might still experiment, draw things on a whiteboard, do whatever helps you think, but you should not consider the side-products of that process to be the result.
You shouldn't. There are fast thinkers and slow thinkers. I consider myself a fast thinker and let my intuition flow through a problem. Then I try to solve it rigorously. My SO is a slow thinker though with an extremely different mindset, we learn physics together. This incompatibility really shows when we are talking about physics, I rely on my intuition a lot, then she asks the hardest questions ever about the most "intuitively simple" things.
I got the questions right! I'm not even an MIT student, heck, not even a university student!
The questions in the article are only a taster of what Daniel Kahneman explored in his research -- and it's amazing such simple ideas took so long to be realized!
It depends on the situation, of course. Sometimes you have to "move fast and (risk that you might) break things". I think the "compleat" programmer should be able to work anywhere on the spectrum from fast to careful, depending on the task. But I certainly spend most of my time on the careful end, and I generally prefer to work with others who do too.