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.
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.
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!
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.
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.
You don't need to enforce it formally. Company culture does that for you if you encourage the kinds of values espoused in these parts. I know it's not a code-y answer, but it's a reasonable and working human one!
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
"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."
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.
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.
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.
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.