7 ms·

You Must Try, and then You Must Ask

366 points by mfringel 13y ago

nhebb 13y 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 13y 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 13y ago
  SO actually encourages users to post questions even if they know and provide the answer themselves.
bifrost 13y ago
Well said. Matt Ringel is spot on here.
mef 13y 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.
- johnbellone 13y 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 http://en.wikipedia.org/wiki/Rubber_duck_debugging
  - mfringel 13y 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!
    - johnbellone 13y ago
      It may not be possible to enforce. My position, some days, tends to lean more towards the DevOps role. Because of past history where often the problems were related to infrastructure issues usually are raised to my team for vetting. It became natural to pass on an issue and wait for team duct tape to take a cursory glance. My position has made a divide between me and some of the developers because I'm out of the normal management structure. It may be a natural "fear of the unknown," but the ways that I try to counterbalance this: * Give them interesting or fun problems to solve; * Debate and challenge their ideas openly; * Admit that (most of the time) I have absolutely no idea what I am talking about. I usually end most coffee conversations egging them on and telling them to test their theories. I think by creating a better team environment the fifteen minute rule may organically be followed.
    - PeterisP 13y ago
badman_ting 13y ago
I like this rule.
cruise02 13y 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 13y 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 13y ago
  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!
joshdance 13y 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 13y ago
  Very similar to Rubber Duck Debugging - http://en.wikipedia.org/wiki/Rubber_duck_debugging http://en.wikipedia.org/wiki/Rubber_duck_debugging
  - moocowduckquack 13y 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 13y 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 13y 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 13y 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 13y 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 13y ago
Is 15 minutes enough time? It might be a small point of contention, but why not an hour?
- twoodfin 13y 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.
  - mfringel 13y 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 13y ago
I might try for 30 minutes, but maybe I'm just stubborn.
umsm 13y 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.
deleted 13y ago
[deleted]
goshx 13y 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.
- mooreds 13y ago
  I prefer to walk around aimlessly, but I agree--sometimes just distracting yourself for a bit does wonders.
  - goshx 13y ago
    yes, that works too :)
jonahx 13y 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 13y ago
  You may want to consider posting with an answer, so that someone else (or yourself in the future) may benefit further.
namenotrequired 13y 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 13y 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.
emilsedgh 13y 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 http://www.catb.org/esr/faqs/smart-questions.html#intro Strongly recommended to hackers.
johnpmayer 13y 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 13y 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 13y 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 13y 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 13y 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.
deleted 13y ago
[deleted]
mkramlich 13y 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 13y 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 13y 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 13y 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.

366 points by mfringel 13y ago

nhebb 13y 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 13y 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 13y ago
SO actually encourages users to post questions even if they know and provide the answer themselves.

bifrost 13y ago

Well said. Matt Ringel is spot on here.

mef 13y 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.

johnbellone 13y 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 http://en.wikipedia.org/wiki/Rubber_duck_debugging
- mfringel 13y 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!
  - johnbellone 13y ago
    It may not be possible to enforce. My position, some days, tends to lean more towards the DevOps role. Because of past history where often the problems were related to infrastructure issues usually are raised to my team for vetting. It became natural to pass on an issue and wait for team duct tape to take a cursory glance. My position has made a divide between me and some of the developers because I'm out of the normal management structure. It may be a natural "fear of the unknown," but the ways that I try to counterbalance this: * Give them interesting or fun problems to solve; * Debate and challenge their ideas openly; * Admit that (most of the time) I have absolutely no idea what I am talking about. I usually end most coffee conversations egging them on and telling them to test their theories. I think by creating a better team environment the fifteen minute rule may organically be followed.
  - PeterisP 13y ago

badman_ting 13y ago

I like this rule.

cruise02 13y 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 13y 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 13y ago
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!

joshdance 13y 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 13y ago
Very similar to Rubber Duck Debugging - http://en.wikipedia.org/wiki/Rubber_duck_debugging http://en.wikipedia.org/wiki/Rubber_duck_debugging
- moocowduckquack 13y 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 13y 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 13y 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 13y 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 13y 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 13y ago

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

twoodfin 13y 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.
- mfringel 13y 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 13y ago

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

umsm 13y 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.

deleted 13y ago

[deleted]

goshx 13y 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.

mooreds 13y ago
I prefer to walk around aimlessly, but I agree--sometimes just distracting yourself for a bit does wonders.
- goshx 13y ago
  yes, that works too :)

jonahx 13y 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 13y ago
You may want to consider posting with an answer, so that someone else (or yourself in the future) may benefit further.

namenotrequired 13y 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 13y 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.

emilsedgh 13y 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 http://www.catb.org/esr/faqs/smart-questions.html#intro Strongly recommended to hackers.

johnpmayer 13y 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 13y 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 13y 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 13y 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 13y 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.

deleted 13y ago

[deleted]

mkramlich 13y 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 13y 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 13y 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 13y 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.