1. Google. 2. The only useful result is a Google cache with a pastebin with a stack trace similar to mine. 3. Examine the pastebin stack trace. 4. Find an embedded userid. 5. Google userid, find github account. 6. Msg user via github. 7. Get response, user doesn't remember solution but remembers they got it from IRC. 8. Search IRC logs. 9. Find response with a link to a commit. 10. Apply the change locally. 11. Profit!

I work on a product with a public bug tracker [1]. It's amusing how often the only useful hit for a problem I'm looking into will be the actual bug in my product that I'm working on.

I imagine the same thing must happen with open source projects all the time, but this is the first place I've worked where it's been the case with commercial software.

[1] http://jira.atlassian.com

     11. Profit!

But I'm not sure if I've hit on it yet. Maybe I should try Quora. ;-)

I actually did debug it (i.e. I found the cause of the bug, just didn't know whether fixing it in the most obvious place wouldn't break anything elsewhere - it occurs it might) but my fix would probably be suboptimal and I'd probably waste the developers' time with a superfluous bug report (and maybe the suboptimal patch too).

Similar use in French means something like "I took advantage [of it]".

...or it could just be a reference to the Underpants Gnomes...

Really, why spend 10 minutes noodling around trying to solve the problem via manuals/thinking, when you might get an answer in 30 seconds otherwise?

IMO, this post has a bit of "Get off my lawn" to it.

I've always encouraged the people I mentor to ask questions of people who may know before spending lots of time on a problem. You get the same level of learning, you get the same realizations, the only thing you skip is your wasted time.

    You get the same level of learning,
    you get the same realizations, the
    only thing you skip is your wasted time.

   Tell me, and I will forget.
   Show me, and I may remember.
   Involve me, and I will understand.

It's not binary.

For example, we have a lot of legacy Delphi code. Delphi 7 has a bug in which it gives incorrect compiler warnings for some of it. I don't care one bit about the history, details and nuances of the bug. The 2 hours I don't spend examining that are 2 hours I can spend learning something useful instead.

It's not yes or no. It's not everything or nothing.

* There are cases where the fastest thing to do is ask your colleagues.

* There are cases where the fastest thing to do is ask your friends (if you have any).

* There are cases where the fastest thing to do is ask Google.

* There are cases where the fastest thing to do is ask StackOverflow.

But there are times when it's best (and not necessarily fastest!) to work on it for a while to see if you can either solve it, or at least get your mind around it enough to understand the solution when it comes.

The very best programmers/engineers/employees/founders/people know when it's which case from the above.

This is true regardless of which method he'd use to figure out a solution.

I do agree it's not binary -- I'm learning Objective C right now, and spent two hours last night tracking down a crash that was ultimately linked to not understanding retain and release semantics. That is worthwhile, and a situation where just asking someone for a fix wouldn't work.

But I think that's a learning issue. If you already know the majority of what's going on, and the rest is just finding a key, then I think searching/asking is perfectly valid.

And really, wouldn't you argue that a programmer worth being called such would always attempt to be involved with finding the answer?

If you can figure it out in under 15 minutes, you've saved time overall versus asking the co-worker.

1) 15 minute gamble on self solving intuition

2) Exhaust any possible solution I can think of even if I have to "be the computer".

3) Google

4) Documentation

5) Ask a co-worker

Sometimes I'll skip from step 1 to 5 if it is dealing with something that I rarely use. Typically this means I don't expect to remember the problem or solution later because of how rarely I visit this part of the application.

This is probably not the best way to do it, but I just remember things more often when I solve the problem myself. After 3-6 months with a new technology, I am frequently able to solve problems in step one.

Not arguing that this can't be an efficient workflow... but I think you pointed why it can fail and fail often. What if you don't find what you are looking for on Google and end up down other roads or dead ends that don't provide the real answer? In those cases 30 seconds can turn into 30 minutes pretty quick.

Mine is:

1. Think

2. Read the API docs again

3. Google/StackOverflow (since google usually points to SO)

4. Think

5. Give up and go play a game for a while

6. Think

7. Another reading of the API docs

8. IRC (I really hate asking other people for help, I really need to get over this problem.)

edit: formatting.

   1. Google
   2. RTFM
   3. Think
   4. StackOverflow
   5. Coworkers/IRC

I would put 'Think' first on my list though because I really enjoy it, and tend to do it whenever I can. Google comes in when I hit a dead end thinking.

I'm the same way, and I'm also trying to get over this. Good luck, fellow turtle!

I think this is a natural extension of the work programmers do these days. We don't spend a lot of time trying to figure out a better compression algorithm, but we sure spend a lot of time trying to figure out why some third party tool is throwing an error after upgrading some other third party tool.

I've had better results on average by searching StackOverflow first, and then Google after if there is nothing on StackOverflow.

(I, too, do a lot of "site:stackoverflow.com" searches on Google these days btw.)

For the former, why dive in and learn something that someone else has already figured out, especially when the "something" is so mundane as an API incompatability? I would much rather spend my time figuring out interesting stuff.

When doing niche development, small mailing lists provide an invaluable asset for these sorts of questions. Oddly, seems strange to ask on such a generalist site as SO.

"You could think of it as putting a low-pass filter on some of the good ideas from the ’60s and ’70s, as computing spread out much, much faster than educating unsophisticated people can happen. In the last 25 years or so, we actually got something like a pop culture, similar to what happened when television came on the scene and some of its inventors thought it would be a way of getting Shakespeare to the masses. But they forgot that you have to be more sophisticated and have more perspective to understand Shakespeare." - "A Conversation with Alan Kay", http://queue.acm.org/detail.cfm?id=1039523

The problem is that researching a problem this way is often pretty half-assed; fixing a deeper problem by googling can be like copy-and-paste programming, rather than solving the actual problem.

(Yes, a programmer can be in flow while doing those activities, but the incidence rate is lower.)

1. Google

2. StackOverflow

3. RTFM/source code

4. Think

5. Instant messenger

6. RTFM/source code

7. Think

7a. Write a blog post about the solution or submit a patch

I do this, too, and I think it's very useful, especially if the solution contains esoteric steps that can only be found in the deep archives of mailing lists.

Among other things, this empowers you to fix problems in the code you are using, rather than just work around them in your own code. Reading the code is the first step toward contributing.

Reading unfamiliar code may be hard at first, but each time you do it, you understand the system better. Eventually you may know the third-party code as well as your own code.

1. Think quickly 2. Search google the fastest possible way (Even if keywords are pretty bad) 3. Search google with the best possible keywords I know 4. With help of results from 3 (In forum/etc.), Research google with new keywords that will improve results 5. Do step 3-4 until I see I can't improve anymore 6. Go directly talking to the best who will know about it. (Which is usually IRC or GitHub issues, etc.)

For most non-trivial problems, I spend times in 1-5. But for lots of problem (like configuring stuff in Linux), I spend lots of time in 2-5. For really rare stuff, I would go up to 6 (Which usually means I found a bug in the library and I'd send a patch).

I'm a bit ashamed by this.. but, I think I spend too much time in 3-5.. after a couple minutes, I think I should just RTFM and figure it out.. but I kind of become crazy and just search search search search until I get the answer I want. Only then, when I have a 90% correct solution, will I read the manual to extrapolate on this. But hey, that's my way.. :)

- off course Google is first; it is cheapest. Back in the day, its equivalent would be a visit to the library. That would come after ask a colleague, visiting one's bookshelf and thinking.

- for some classes of problems, such as algorithm selection, 'Google' requires quite some thinking about what your problem actually is.

- for others, such as figuring out the cause of weird error messages, Google may be about the only option, even though it isn't particularly good (e.g. because your query gives a zillion 'me too' posts plus a couple of five year old 'I did x, and it went away', where there is no reason to expect x to have any effect on the problem, where x seems to be pure overkill (reinstall, reformat), or where the poster readily admits 'it went away for a while'.

- typically, this isn't an either/or proposition. Googling, in particular, does not (have to) rule out thinking.

But in many situations, the "programmer" is wearing many hats at once. And in that case, much of the "thinking" or other due diligence that a programmer should be expected to do (according to John, I think reasonably) may have been accomplished before this checklist is taken up by a programmer.

There are still many programming jobs which revolve solely around programming and programming alone, but even in those cases, I think that John's "Think" step would be given more than just a passing glance early in the process.

1. rtfm

2. think

3. read the relevant source code

4. put in some print statements or use stepper and inspect variables i am interested in (depending on the system).

goto 1

I'll never actively engage community via stackoverflow or irc, I'll only check for existing questions and answers since I don't have time to actually wait for responses.

Occasionally, I'll bring Think to the head of the stack is if the problem sounds fun--or seems like I would enjoy the challenge of solving it.

Balance is the key. Taken to an extreme, the thinking approach can kill a project. After all, when it comes to computing, we are all standing on the shoulders of giants. The position that we should always solve our own problems by "thinking" suffers from irreducible complexity. Why not implement our own language? Brush off those compiler skills. See you in 5 years when you have the beginnings of a mature language. Meanwhile, your competitor, who used an existing language, will be 5 years ahead of you on their project. The same applies to "Googling" answers, which is just a metaphor for looking for prior work. If I find a solution to a complex problem in 2 hrs of Googling and reading, while my competitor hammers out their own solution, there's a good chance I'll gain a lead on them. There's also a good chance that my solution will be more flexible, leading me to continue development while my competitor is still extending their solution.

As usual, "it depends". What are the priorities at the time? Is the team under a deadline (ha!)? Are we solving a problem that is considered central to our solution? In other words, would we gain a competitive advantage by building a better mouse trap? Do our programmers have the experience and talent to build said mouse trap? Few companies have the resources to hire people focused enough to solve difficult CS problems, so scouring the internet for leads on the best solution is never a bad idea, IMO. This applies even if a solution immediately comes to mind. At least "check your math". Maybe you'll find something you didn't think of. If you've got Facebook/Google money, well then throw this advice out the window. Go hire a six-figure PhD in your specific domain and make history.

When faced with a difficult problem, the "think through the problem" method often requires the most time, and there is no guarantee that you'll arrive at the most efficient solution. Depending upon what you consider difficult, there may be exceptions to this rule, but if you are the kind of programmer that needs to Google solutions to trivial problems, you've got much bigger challenges ahead.

For most competent programmers, Googling usually means looking for a library that accomplishes a task, or trying to locate the most efficient approach to implementing a non-trivial task. In these situations, Googling to locate an answer has the added benefit of context. It's rare that you find a solution in a vacuum. There is usually some discussion, so you're benefiting from the contribution of many people. Few companies have the resources to hire a large team of developers who specialize in all the important areas for a given project. Normally, you end up with a team -- sometimes a team of one -- of generalists who must look for solutions to specific problems that falls outside their area of specialty. In this case, Googling solutions makes a lot of sense.

Again, balance.

1) Ask the Googacle

2) Read the source code

3) Give up, try something completely different.

Usually if I get to 3 then it means I'm going against the grain, trying to do something that just isn't meant to be done that way. Recognizing that point is an important life skill. :)

Yes.

Assuing a professional attitude, why not?

By professional attitude, I mean thet the programmer in question gets a good understanding of the problem and the solution from his solution-source of choice.

    gets a good understanding of the problem

If Quora or SO doesn't yield enough understanding for a given problem, that's hardly an issue. Go to N+1.

(At any rate: I'm not familiar with Quora, but SO answers often have good explanations and links to official documentation and well-written instruction material.)

    well-written instruction material

1. Google

2. RTFM

3. Think

4. Coworkers

5. StackOverflow