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.
If you have struggled for more than
90 min, you may ask that question
(exceptions exists).
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).
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).
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.
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?".
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?
