▲ 43 points
back
20 comments
My two-year-old son is adept at this technique. Unfortunately I am not sure he always listens to my responses. An example copied from one of my recent blog posts:
We have interesting conversations in the front hallway on weekday mornings when he tries to prevent me from going to work.
“No Daddy go!”
“Daddy has to go to work.”
“Why Daddy work?”
“Daddy has to work so that he can make money.”
“Why money?”
“Because we need money so that we can buy food.”
“Why?”
“Because we need to eat.”
“Why?”
Why indeed? I used to believe that when I had a child, I would always try to explain things to that child and never resort to the pat answers I’d hear from other parents (”just because”). My child is only two and he is already defeating this goal. Why DO we need to eat?
You can answer that question, sure, but ask enough “whys”, and you’ll find yourself trying to explain the nature and reasons for existence of the universe – to a two-year-old.
I spent some time worrying about this just before I had kids, running scenarios like this through my head. My daughter's first question for this destroyed any value such rehearsals might have had by saying "How do you know?"
The ultimate answer to which, of course, is "I read it on Wikipedia".
Also acceptable, telling your child to "just google it".
I know you're being facetious, but I actually sometimes say something like this to my son when he asks me a question that I can't give an answer I'm satisfied with. I usually say something like "I don't really know, but let's look it up together."
Yes, googling can be a family experience. Binging, however...
ROFLMAO. Startup rule #24: When picking the name for your project, make sure it won't embarrass you when used as a verb.
Well, this was before wikipedia, and the kids did not yet have computers.
Sometimes there's nothing wrong with "I don't know".
Why don't you know? ;-)
But do you then to this add "...but I'll try to find out for you" ?
Also a great way to distinguish good programmers from bad.
If they can't explain a phenomenon beyond "when I do <x> it works/breaks/quacks like a duck" and are satisfied with that level of understanding, that's a massive red-flag.
This is a very efficient way of picking out even the young guys & gals who will end up being good engineers.
More specifically, turning this into a habit will bring out the cached ideas/thoughts that you use.
Cached ideas/thoughts are conclusions that you or someone else has made, that you accept as a useful variable that you can plug into situations when necessary. Problem is, these conclusions are sometimes wrong. So, after you make a habit of "asking why" until you are satisfied, you'll find yourself catching these cached thoughts even in every day speech.
But, there are some things that are best to just accept. Like, some uses of CSS. I am fully comfortable using other people's fixes without completely understanding how it works.
There is a balance that needs to be found. It's like memorizing things by rote vs. knowing why said things work. It is as much a mistake getting caught up figuring out why everything works as learning everything at surface level. But, the latter is far more frequent.
A better principle is ABQ, since few things have a neat single root cause that some magic number of questions converges on:
"5. Why? - I have not been maintaining my car according to the recommended service schedule. (fifth why, a root cause)"
6. Why? - Because I didn't think it a high priority relative to my other activities
7. Why? - Because ...
All entrepreneurs need to put their ideas through the "why" test at least 5 times. If you have concrete reasons and answers, then your ideas are good and well thoughtout.
Candidates that can't answer the why test all 5 times needs to think things through a little more.
This first scene from HBO's Lucky Louie is the best example of this: http://www.videosurf.com/video/lucky-louie-101-58075787
Never seen Lucky Louie but the similar scene from Louis C.K. standup is fantastic.
I found http://www.startuplessonslearned.com/2008/11/five-whys.html to be a better explanation of this phenomena.
As other people have pointed out, this doesn't exactly arrive at a "root" cause, just a convenient one for the asker. You can keep asking "why?" until the problem is no longer your fault.
Interesting but does 5 times work for everything or just some specific problems? I would agree that constantly asking why is a good thing but I'm just not sure about this 5 thing
It's just a rule of thumb, like the "rule of 7" when it comes to cognitive load. The point is to continue past the surface issue until you find the real problem. Fixing a lower-level problem (like not having automated testing) has much more value than fixing a higher-level problem (like fixing regressions when they occur in your software).
I'd always heard it put as the "seven whys", but yes, it does work.
The number is probably irrelevant, but the idea is to keep pushing for the deeper meaning (or root cause, in this case). If you can keep your reasoning from being circular ("the sky is blue because it isn't any other color"), you either get the answer, or learn that you don't know enough to get the answer.