Programmer problem solving sequence: should it be like this?

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!

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.

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.

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.

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.

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

"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.

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

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.

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.

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.

1. Google

2. RTFM

3. Think

4. Coworkers

5. StackOverflow