You Must Try, and then You Must Ask

https://blogs.akamai.com/2013/10/you-must-try-and-then-you-must-ask.html

by mfringel • 13 years ago

366 48 13 years ago

blogs.akamai.com

bifrost• 13 years ago

Well said. Matt Ringel is spot on here.

mef• 13 years ago

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.

mooreds2• 13 years ago

I agree, this is great. I run a small team and the author just summed up what I try to convey to everyone on the team. I just emailed it off to everyone.

johnbellone2• 13 years ago

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

mfringel2• 13 years ago

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!

nknighthb• 13 years ago

There are times where questions are fielded to me and it was simply "this does not work"

I want this to be defined as misconduct. People need to be fired for repeat offenses. If they can't at least explain what they did and what the actual result was, they're incompetent. If they won't, they're ridiculously lazy. In either case, they need to be out of a job.

jakejake• 13 years ago

As someone who gets asked many more questions than he asks himself, I think this is a fantastic rule of thumb. It's annoying when somebody asks me a question which I can tell they spent no time troubleshooting. But, it's possibly even more annoying when I go check in with somebody and find out they have been spinning their wheels for a day and a half on a 5-minute problem without telling anybody. I would rather they err on the side of bothering me than burn hours upon hours of time.

badman_ting• 13 years ago

I like this rule.

cruise02• 13 years ago

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.

toadi• 13 years ago

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• 13 years ago

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!

joshdance• 13 years ago

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• 13 years ago

Very similar to Rubber Duck Debugging - http://en.wikipedia.org/wiki/Rubber_duck_debugging

moocowduckquack• 13 years ago

I sometimes use the computer as a stand-in, sort of like, "So what I want you to do, is to take this over there and..."

knappe• 13 years ago

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

elements• 13 years ago

This happens to me often. It's also the reason I love the fact that StackOverflow automatically searches for the text in the question title box as you type it in. There have been a few times where I will start to write out a good, descriptive title for my problem, and realize that I've been searching for the wrong things all along.

tmoertel• 13 years ago

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.

joeblau• 13 years ago

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.

diminoten• 13 years ago

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

twoodfin• 13 years ago

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.

mfringel2• 13 years ago

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.

squozzer• 13 years ago

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

umsm• 13 years ago

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.

goshx2• 13 years ago

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.

mooreds2• 13 years ago

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

goshx2• 13 years ago

yes, that works too :)

jonahx• 13 years ago

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• 13 years ago

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

namenotrequired• 13 years ago

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!

falcolas• 13 years ago

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.

nhebb• 13 years ago

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• 13 years ago

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.

FrojoS• 13 years ago

SO actually encourages users to post questions even if they know and provide the answer themselves.

emilsedgh• 13 years ago

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

Strongly recommended to hackers.

johnpmayer• 13 years ago

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.

vsvn• 13 years ago

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.

Apocryphon• 13 years ago

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?

616c• 13 years ago

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.

pasbesoin• 13 years ago

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.

mkramlich• 13 years ago

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.

SilasX• 13 years ago

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.

DrPhish• 13 years ago

"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

cl3m• 13 years ago

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.

You Must Try, and then You Must Ask

Related Stories