
Why slow thinking wins - JohnHammersley
https://www.bostonglobe.com/ideas/2015/07/25/the-power-slow-thinking/ToZbzYl7rG0yVMCtsZ7WnJ/story.html
======
ScottBurson
In my last job we hired a guy who had won TopCoder competitions. I expected
him to pump out code fast. Instead he turned out to be the most careful,
painstaking programmer I have ever worked with. Sometimes it seemed like he
was taking longer than necessary, but in two years, as far as we knew, he
never shipped a bug. Seriously: no bug was ever found in code he had signed
off on.

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.

~~~
verbin217
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.

~~~
beagle3
"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.

~~~
collyw
I think more _large_ _scale_ projects have succeeded using waterfall than
Agile.

~~~
beagle3
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_ ?

~~~
collyw
[http://news.slashdot.org/story/13/05/25/139218/worlds-
bigges...](http://news.slashdot.org/story/13/05/25/139218/worlds-biggest-
agile-software-project-close-to-failure)

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

------
joaorico
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...](http://www.fiddlemath.net/stuff/conditions-for-intuitive-
expertise.pdf) [2] Strategic decisions: When can you trust your gut?
[http://www.mckinsey.com/insights/strategy/strategic_decision...](http://www.mckinsey.com/insights/strategy/strategic_decisions_when_can_you_trust_your_gut)

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

~~~
falcolas
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.

------
mynameishere
_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.

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

~~~
kriro
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.

~~~
nostrademons
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.

~~~
eutectic
I suspect that they are a lot easier when you are primed with the idea that
they are trick questions.

~~~
nostrademons
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.

------
mizzao
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](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?

~~~
itistoday2
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.

~~~
dhimes
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.

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

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

~~~
kriro
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

------
haihaibye
>> Daniel Kahneman, the only non-economist to be awarded the Nobel Prize in
economics

John Nash (mathematician) also won the econ Nobel

~~~
beagle3
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](https://en.wikipedia.org/wiki/Kenneth_Arrow)

[1] [http://www.nobelprize.org/nobel_prizes/economic-
sciences/lau...](http://www.nobelprize.org/nobel_prizes/economic-
sciences/laureates/1997/press.html)

[2]
[https://en.wikipedia.org/wiki/Robert_Aumann](https://en.wikipedia.org/wiki/Robert_Aumann)

[3]
[https://en.wikipedia.org/wiki/Nobel_Memorial_Prize_in_Econom...](https://en.wikipedia.org/wiki/Nobel_Memorial_Prize_in_Economic_Sciences)

------
Rzor
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?

~~~
roflmyeggo
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.

~~~
logn
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.

~~~
collyw
For me it was a case of reading the question properly, rather than skimming it
and assuming you knew what it was asking.

------
omginternets
Because fast thinking isn't really _thinking_.

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

------
gitaarik
I would call it "thoroughly thinking" and "ignorant thinking" instead of fast
and slow.

~~~
wqgr1434
... 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.

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

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

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

------
apineda
So how does one train in slow thinking?

~~~
lukaslalinsky
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.

------
azeirah
I got the questions right! I'm not even an MIT student, heck, not even a
university student!

~~~
JohnHammersley
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!

