
You Must Try, and then You Must Ask - mfringel
https://blogs.akamai.com/2013/10/you-must-try-and-then-you-must-ask.html
======
mef
This is so great.

By forcing yourself to try for 15 minutes, you gain a deeper understanding of
what you're troubleshooting so that, even if you don't fix it in 15, next time
you're in a better position to troubleshoot than you were the last time.

And by forcing yourself to ask for help after 15, you not only limit the
amount of banging-your-head time, but you also get to see how the other person
solves the problem while all the details are still fresh in your mind, so that
you'll more likely have a deeper understanding of why what you were doing to
fix it wasn't working, and why the ultimate solution actually worked.

~~~
johnbellone
It would be great if I could force every single developer that I know to read
this. And after that enforce it.

At least after fifteen minutes you have enough information where you can,
hopefully, clearly articulate your question with enough detail. There are
times where questions are fielded to me and it was simply "this does not work"
where after fifteen minutes of legwork the answer was solved along the way.

Often the answer is found simply by questioning yourself.
[http://en.wikipedia.org/wiki/Rubber_duck_debugging](http://en.wikipedia.org/wiki/Rubber_duck_debugging)

~~~
mfringel
Author here. You bring up a very good point. How _do_ you enforce the 15
minute rule?

Part of it is incentive structure. That is, detecting when a team implicitly
rewards augering in on a problem when stuck. After that, showing that there's
no loss of credibility for asking questions _and_ that answering reasonable
questions is part of the job.

After _that_ , subsequently rewarding people who "try and ask", which will net
out to more productivity anyway.

Wow. Yeah. There are _many_ paragraphs to write about this. Thanks for the
food for thought!

~~~
read
There's something you might have missed. When I approach a problem like this I
notice I solve it only after I give up.

It's not spending 15 minutes to go over all assumptions that makes me solve
it. It's telling someone I can't solve it. It's the act of saying I can't do
it.

I often start writing an email telling someone I can't solve a problem, and
while writing I realize something I haven't tried. Then I stop, go try it, and
it turns out to solve the problem. But if I don't start writing that email,
and instead try to work on the problem for 15 more minutes, I don't solve it.

It's as if I don't take the problem seriously otherwise.

This is very similar to the 15 minute rule, only it's more efficient, since it
takes less than 15 minutes to write that email.

So I would argue solving the problem has more to do with admitting you can't
solve it than it has with going over assumptions. It triggers something in
your brain that frees it to look at options it hasn't looked at before.

I thought it was the possibility you might embarrass yourself to the person
you are emailing that helps solve it. But the strange thing is I also solve
problems only after I send that email. My mind refuses to look at the problem
from a different angle otherwise.

------
joshdance
Often times I start writing out my question like I would post it to
StackOverFlow. The very process of writing out what I know, what I don't, and
what I have tried very often leads to a solution.

~~~
slig
Very similar to Rubber Duck Debugging -
[http://en.wikipedia.org/wiki/Rubber_duck_debugging](http://en.wikipedia.org/wiki/Rubber_duck_debugging)

~~~
knappe
I rubber duck a lot, but to my cat. He doesn't seem to mind and often gets
petted as well. Win win.

------
nhebb
I'm a one-man shop with no one to bounce problems off of, so I rely on Google
and Stack Overflow (or other forums). In the past when I got stuck and posted
a question, frequently I'd solve the problem myself almost immediately
afterward.

So now when I'm tempted to ask a question on SO, I write out the question in a
text editor, giving as much detail as possible. It's not a 100%, but I've
found that going through the process of trying to frame a question
intelligently goes a long way toward figuring it out myself.

~~~
avalaunch
I think that's fairly common amongst developers - solving the problem minutes
after posting the question.

My advice is to post the question anyway. And then when you solve it minutes
later, post the solution too. That way you'll be providing a net increase to
our collective knowledge while also helping yourself.

------
falcolas
This works if, and only if, the cost of you failing is limited to the cost of
your time. If you're starting work on a metal lathe, ask before trying (the
cost of failing is your life). If you're working with an expensive physical
material, ask before trying (the cost of you failing is the loss of that
physical material).

More relevant to HN viewers: If you're doing work on a production server, ask
before trying. The cost to your corporation of you failing and bringing down a
mission critical service is typically greater than the context switch of one
additional person to make sure you're doing it right.

------
goshx
I like the rule.

I'd suggest to try also with a step in between. Something like: try for 15
minutes, if you still can't find the solution, go for a quick break, like
getting a coffee, and if the solution still doesn't magically appear, ask
someone.

I lost count of how many times I solved a problem while getting up to get
coffee, after trying hard to find the answer for a few minutes. I can't be the
only one.

~~~
mooreds
I prefer to walk around aimlessly, but I agree--sometimes just distracting
yourself for a bit does wonders.

~~~
goshx
yes, that works too :)

------
emilsedgh
This is very similar to 'How To Ask Questions The Smart Way' written by Eric
Raymond.

[http://www.catb.org/esr/faqs/smart-
questions.html#intro](http://www.catb.org/esr/faqs/smart-questions.html#intro)

Strongly recommended to hackers.

------
tmoertel
I like this rule for one reason beyond those the author mentioned: it benefits
the people you're asking for help, by sharing with them problems that have
been pre-qualified as interesting.

------
toadi
Sometimes whie trying to explain the problem to someone else. I find the
solution myself. So maybe after the intial 15 minutes try to explain it.

~~~
nicolethenerd
[http://en.wikipedia.org/wiki/Rubber_duck_debugging](http://en.wikipedia.org/wiki/Rubber_duck_debugging)

ETA: oh snap! Didn't realize that someone else posted this link above as a
reply to a different comment. Oh well, you can never have too much rubber duck
debugging!

------
jonahx
I run into this phenomenon often when posting on SO.

In the process of writing up a clear and detailed post, which often involves
simplifying the problem into something reproducible on jsfiddle, I suddenly
see the answer.

Instead of hitting submit I can just close my browser tab.

~~~
Yahivin
You may want to consider posting with an answer, so that someone else (or
yourself in the future) may benefit further.

------
cruise02
This is a pretty good rule of thumb for posting questions online (Stack
Overflow) as well as asking your co-workers. Take the time to understand the
problem yourself so you can better present it to someone else.

------
pasbesoin
Trying first reduces the burden on the person you eventually ask. If you made
a good effort, you will go into the conversation knowing a lot more and having
a contextual awareness (in detail) that you otherwise would not have.

The person you ask can focus on the parts that you didn't figure out for
yourself. And, you may have gained a different perspective and/or insight into
deficiencies or additional options that is actually of interest to the person
you talk to (write, IM, etc.).

Viola. You just turned a lecture into a more interesting and engaging
conversation.

------
diminoten
Is 15 minutes enough time? It might be a small point of contention, but why
not an hour?

~~~
twoodfin
I think "stuck" means you don't have any idea how to make progress. It's not
the same thing as, say, encountering a problem in an area of the code you've
never dealt with before. In that case, spending an hour or more working
through the source is likely worthwhile.

15 minutes of documenting exactly why you have no idea how to proceed sounds
about right. If you need longer, you probably haven't whittled down the
problem sufficiently, and you can make progress that way.

~~~
mfringel
Author here. That's more or less how I define it. "stuck" means "completely
stuck," as in "no forward progress."

More importantly, by the time a person realizes they're going in circles,
they've _actually_ been going in circles for probably twice as long.

------
joeblau
I've learned a lot and wasted a lot of time doing this. Sometimes I think I'm
almost there and 15 minutes turns into 2 days.

------
616c
This is very cool, and this is how I have approached my sysadmin and
programming work over the years.

When I started, I had very little experience, but a willingness to learn. My
boss hired me anyway, and it moved from pushing paper to labs to "OK, we need
to update this web application" and "I need you to learn how to deploy a very
customized Windows image for 300 computers, and learn to maintain them." Since
I was much younger, first as a student and then a full-time employee at uni,
it was easy to ask my bosses (the first, if you can believe this, actually
wrote his own code to hide a password in the bootloader to run some admin task
on the first boot after imaging and then delete after completion; with Windows
installations and incosistency, it took him months to get that write; he now
is a full-time lit nerd and author, talk about renaissance man) and tell them
everything I did and needed help. Not only did that teach me to solve the
problem, it taught me how to approach computer problems (kind of like the OSI
stack, but more general than networking, and not as shitty as "turn the
computer on again and off again") and then onto "how do I debug stupid coding
mistakes in scripts with the least time possible" (answer: it might not be a
production app, but make sure your scripts have good on-and-off logging
infrastructure or you will be sorry).

Unfortunately, I moved on from that job. And if this long-winded post is any
indication, I am now seen as too chatty and annoying with this approach where
I work. Some people get it, while as the other more senior infrastructure
people see it as me questioning them when I ask for explanations or better
tips to troubleshoot issues I could see (not that are there, but potentially
could see) from my end and know when to leave them alone. As others pointed
it, it is essential to enforce this on everyone, and in many institutions,
that is seen as being chatty and nosy.

I learned a lot through my mentors, and I wish this could be imposed
everywhere I worked and work, but many oppose this as questioning authority. I
wish it was different, but oh well.

------
umsm
Whenever I get stuck on a problem, I try to clear my head. That usually
involves tackling another task, getting some fresh air, or just going home.

I noticed that going home early and tackling the problem early the next
morning helps more than the 2-3 hours I spent with no success.

------
DrPhish
"I do not believe that any scientific teaching ever was more thorough, or
better fitted for training the faculties, than the mode in which logic and
political economy were taught to me by my father. Striving, even in an
exaggerated degree, to call forth the activity of my faculties, by making me
find out everything for myself, he gave his explanations not before, but
after, I had felt the full force of the difficulties; and not only gave me an
accurate knowledge of these two great subjects, as far as they were then
understood, but made me a thinker on both."

    
    
       -John Stuart Mill: Autobiography

------
vsvn
We use and apply this basic rule at work and it works wonder. A lot of time,
the developer could figure out the answer before asking or during the
discussion with another developer.

I think the reason why this works well is because you are force to document
and make it as easy to understand as possible. There are complex problems, but
it is easier to solve if those problems are broken down into solvable pieces.

------
johnpmayer
This is great advice, and very difficult advice if you have a ego that
dislikes not knowing the answers. It's also something that is doubly important
for devops - don't let production issues sit idle because you're afraid to ask
how to fix something! I know that I still struggle, but I'm getting better and
am much better than when I started.

------
bifrost
Well said. Matt Ringel is spot on here.

------
SilasX
I agree, but you have to have to be on guard for the _opposite_ problem, which
is taking too long on your tasks because "you don't ask for help enough".

I, um, "know people" that have been on that end of the spectrum.

------
squozzer
I might try for 30 minutes, but maybe I'm just stubborn.

------
Apocryphon
This is a great idea. I'm sad that I didn't learn it earlier, in college. I
wonder why it seems like most of us in this thread hadn't, as well?

------
namenotrequired
I suspect this would work great even if you don't have direct workmates but
know some people with expertise in your area anyway. I'd love to try it!

------
cl3m
Amazing rule but as a developer I'll probably try for more than 15min :-)
however I'm sure it make sense at the company level.

------
badman_ting
I like this rule.

------
mkramlich
There's a wisdom in his rule, but not if applied too strictly. The opposite is
also a problem. To wit, at times the web seems to be _overflowing_ with people
who neither tried too hard, if at all, nor did the _obvious_ set of things
that an intelligent competent person would have done in their circumstances.
Also the more you try, the deeper, the harder, broader, the more you learn,
which makes you more efficient in the future. And it gives you _deeper_ , more
inter-connected understanding of the world. Something that will give you an
edge over the masses who just Google for answers, looking at every problem as
a flat-time key-value lookup. If you never learn how to start with the key,
and manually reach that value (the answer), the old fashioned way, you'll be
missing out on a lot that will serve you well all the rest of your days. And
help make you more of a producer and problem solver yourself, rather than a
parasite or info polluter. Become the person everybody else turns to when
they're stuck. Don't become the person who always has to turn to others. A
world full of this latter kind of person is a world that will suck and
eventually fail. Optimize in the other direction. Everybody will be better
off.

