The Ten Minute Thinking Rule
What’s the problem?
This idea was shared with me during a retrospective session at $employer when I was expressing some frustration at people starting to:
Ask first, think never
I’m at least as busy as the next person and I have my own mountain of work to complete. Despite being regularly cantankerous, grumpy, cranky and disagreeable people still come to me with a variety of questions … I think I have a good combination of detective skills, google-fu and luck that makes me appear more magical than I really am.
The Ten Minute Thinking Rule
Simply put:
You may only interrupt another co-worker to ask a question if you have sat on your own for ten minutes and tried to figure out the solution yourself
Corollary
When asked, you must be able to demonstrate that you’ve made some effort
The Ten Minute Thinking Rule isn’t an exercise in pretending you’re thinking.
Some ‘thinking’
Thinking also includes basic investigations. Consider some of the following:
- You have an error message - what results do you get from $search_engine?
- You have a code/SQL/… snippet - what results do you get from grep or ack?
- You sit nearer to other smart people - what did they say when you asked them? — The Ten Minute Thinking Rule is generic - don’t mindlessly interrupt anyone
- What other thoughts and questions have you processed in your ten minutes? — Do you vaguely remember seeing an email/bug report/internal wiki page that might have been relevant? Did you find it? Why wasn’t it helpful?
In Conclusion
Don’t get me wrong; I am more than happy to help people with problems where I can. I just get frustrated at the (apparent) lack of effort on the interrupting-person’s part.
Demonstrating that you’ve made some effort to solve your own problem is likely to encourage much higher levels of response and helpfulness.
Demonstrating that you’ve made no effort at all will likely result in very little help at all, deflection somewhere else and loss of karma in my internal tally chart.
google-fu seems to be an elusive talent.
Thinking through a problem is a skill that has to be learned, and many people don't have it. I've noticed that the kids I tutor (11-13 years old) frequently ask for help before thinking. If their first guess after glancing at a word problem is that they need to multiply two numbers, they'll say, "Do I need to multiply here?" And if I say anything other than yes, they'll start trying other guesses: "Divide, then?" Of course, it's a lot easier to say yes when they guess right than to say, "Think it through. Read me the problem and tell me where you're stuck." Usually just reading it out loud to me (so they actually have to read every word) is enough to make them see the answer. But they have to think it through if they're ever going to learn that skill and get in the habit of using it before asking.
I agree, but I believe that thinking things through is a skill that can be taught.
When I'm helping on IRC, I tend to annoy people by asking "What happens when you try it?" to many of the questions they ask me. "Will this work?" "What happens when you try it?" "Can I use X to do Y?" "What happens when you try it?"
If they're right, they figured it out themselves. There are few greater feelings than that. If they're wrong, they know they can tell me what happened (because I asked) and I'll point them to the next step in the thinking-things-through process.
The hard part for me is to still say "What happens when you try it?" when I know absolutely that it is the wrong answer.
My best friend is a teacher, and she's set up something similar for her classes: It's called the "Three before me" rule.
If her pupils have a question, they have to first check their own notes; then look through their textbooks; then ask the person they sit next to. Only if they've done all three and still don't know are they allowed to put up their hand and ask the teacher their question.
If the teacher can find the answer in their notes or textbooks in under a minute, they're allowed to be extremely sarcastic :)
It's cut the number of questions to less than half what they used to be.
The problem is even bigger at larger groups of people, I work for a big company and I support users that use the products we develop (in house).
Users often don't even read the error message, they almost immediately make a call or send me an email that they have a problem. Not to mention try to look it up or open a log.
I have said many times that "The recruiters should test the reading skills of our developers".
Having said that, I think most developers are ok, there is that small group of developers (that seems to be unable to read :) ) that makes 80% percent of the "noise".
I wish I could post this on our internal wiki.
According to "The Practice of Programming" (Kernighan and Pike), one university computer help centre kept a teddy bear on the reception counter. Students weren't allowed to speak to a support person until they had explained their problem to the bear. It halved the number of requests that got to people.
Pick an entity of your choice; an Einstein action figure, a stuffed camel, whatever, and make that your primary gatekeeper.
I'm guessing "talk to the teddy bear" worked more like "put on this dunce cap," "stick your hand in this bucket of ice water," or "run around the building 3 times" as a way of "helping" the students. Put enough BS hurdles in front of people, and many will simply give up. Phone and cable companies have known this for years, hence the automated menu trees between you and someone who can fix your problem.
> I'm guessing "talk to the teddy bear" worked more like "put on this dunce cap
That probably depends a lot of the environment.
I often help colleagues by just listening to them explaining their problem - the mere act of having to explain the problem out loud to someone else is surprisingly efficient.
Often they only get half way through the description when they go "Ahh, ok, I see the solution now. Thanks!", and all I did was to act like the teddy bear and listen.
The same thing often happens when I explain a problem to my colleagues, of course.
The difference to phone- and cable companies is that their automated menu trees does not make you explain your problem "out loud" unlike the teddy bear; another flaw in the analogy is that usually when you call them, _they_ have to fix something, when you have a programming problem _you_ (often) have to fix something.
See also 'Rubber Duck Problem Solving': http://www.codinghorror.com/blog/2012/03/rubber-duck-problem-solving.html