I assigned a quite simple task to one junior developer today, and he kept pinging me EVERY 5 minutes for HOURS, asking STEP BY STEP, what to do. Whenever something went wrong, he simply copy&pasted the log and basically wrote, "An exception occurred. What should I do?"

So I finally had to tell him, "If you want to be a developer, please start thinking a little bit. Read the error message. That's what they are for!".

I also however, tell junior developers to ask questions before spending too much time trying to solve it themselves. This might sound contradictory, but I feel there is some kind of an implicit rule that distinguishes questions that should be asked fairly quickly and that should not (and I try to follow those rules when I ask questions..)

So my question is, do you have any rules that you follow, or expect others to follow on asking questions? If so, what are they?

Let me start with my own.

1. If you have struggled for more than 90 min, you may ask that question (exceptions exists).
2. If you haven't struggled for more than 15 min, you may not ask that question (if you are sure that the answer can not be found within 15 min, this rule does not have to apply).
3. If it is completely out of your domain and you do not plan to learn that domain, you may ask that question after 15 min (e.g. if I am a java programmer and need to back up the DB, I may ask the DBA what procedure to follow after googling for 15 min).
4. If it is a "local" question, whose answer is difficult to derive or for which resources is difficult to get (e.g. asking an colleague "what method xxx does" etc.), you may ask that question after 15 min.
5. If the answer for it is difficult to derive, and you know that the other person knows the answer, you may ask the question after 15 min (e.g. asking a hibernate expert "What do I need to change else to make this work?".
6. If the process to derive the answer is interesting and is a good learning opportunity, you may ask for hints but you may not ask for answers!

What are your rules?