

Programmer problem solving sequence: should it be like this? - RiderOfGiraffes
http://www.johndcook.com/blog/2010/10/22/programmer-problem-solving-sequence/

======
praptak
War story ahead:

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!

~~~
fogus

         11. Profit!
    

What defines profit in this case? I realize that this post was likely tongue-
in-cheek, but I think my question is still valid. I'm trying to explore the
answer to that question myself: <http://blog.fogus.me/2011/02/28/the-keepers-
of-answers/>

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

~~~
praptak
Valid question. The result in this case was getting a patch that was already
committed into the development branch, just not yet released.

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

------
bradleyland
Short answer: Yes, I think it should be this way, but with caveats.

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.

~~~
bradleyland
I want to follow this up by saying that I have tremendous appreciation for
academics in software development and purer forms of CS in general. I
encourage programmers I work with to expand their skills and "think" about
problems. It is unacceptable in our organization to simply copy/paste a
solution. Before selecting a library, we always google "[libname]
bug|issue|slow" and look through the results. Whenever time permits, we pick a
library and dig in. In short, I expect my team to grok our solutions, not
simply plug them in and run.

Again, balance.

------
mrcharles
I think, honestly, that this is a reasonably efficient workflow. Googling
takes the place of 'ask a coworker' in situations where that's not possible.

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.

~~~
RiderOfGiraffes
To a large extent I agree with you, but there is one thing I pause about:

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

Here we diverge. As Confuciussaid:

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

Sometimes, and for some things, that time spent working out bits of a solution
- _even if you fail and ultimately ask for help_ \- is not wasted. Sometimes
it's priming you to be in a better position to understand the solution you're
given.

It's not binary.

~~~
Deestan
But do I really _need_ or _want_ to know, remember and understand the nuances
of each and every of my problems?

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.

~~~
RiderOfGiraffes
Exactly - _it's not binary._

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.

------
younata
Huh.

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.

~~~
alphamerik
It amazes me that people would put coworkers second. Those people can be very
annoying because I feel like their only purpose is to leech knowledge rather
than do any real work. OP's list is the lazy programmer's list. Taking breaks
to think about the problem is good, my order of operations is something like:

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

Even going to IRC can be dangerous, was told to read the f-ing kernel source
when trying to ask questions about the darwin kernel API documentation once.

~~~
TillE
I like that order. Don't waste your time or anyone else's if it's a simple
problem that can be solved with a direct Google search. But definitely _think_
before asking.

------
towelrod
Google and StackOverflow are kinda the same step. I don't think I've ever gone
to search specifically on StackOverflow, but google finds the answer there
quite often.

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.

~~~
dikbrouwer
I'm not so sure about "Google and StackOverflow are kinda the same step". In
my experience, Google sometimes points to StackOverflow, sometimes to a
copycat (really annoying), and sometimes there is no good result.

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

------
jarin
While it might not be ideal from a critical thinking standpoint, it's pretty
efficient. My process usually goes like this:

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

~~~
giu
> 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.

------
robryan
Really depends if your surrounded by coworkers who are amazing at what they do
or you feel way above your team and assume it's safe just to go to Google and
get the answer rather than whatever a coworker comes up with or thinks is the
right way of doing things.

~~~
dpritchett
I've never had a job without at least one programmer I could bounce ideas off
of. Sounds awful.

------
silentbicycle
The problem with "solving" problems this way is that bad feedback loops form:
people who are only slightly better-informed than complete newbies repeat
questionable advice they don't completely understand, crowding out better
answers.

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

------
flyosity
I really try not to bother coworkers unless I'm totally stuck. They're all
busy working on their own projects, and taking them out of the zone to help me
doesn't seem fair, especially if they don't know the answer either because
then I interrupted them for nothing.

~~~
T-hawk
The best way to ask a coworker for help: Look for a moment when he or she is
not in flow that you will break. Returning from the water closet or coffee
maker, or just if you happen to glance at their screen and see Gmail or HN or
something.

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

------
ohyes
Here's mine:

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

------
mbrubeck
"Read the source code" should be on the list (if you have access to the code
in question).

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.

------
Tichy
I wonder if it would be possible to write a chat bot that gets the
StackOverflow crowd to code for it. It would keep asking questions and nagging
for code examples.

~~~
duck
Possible, yes... but to get the results you want, no.

------
d0m
Mine is something like this (Where my goal is to get the answer as fast as I
can) :

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.. :)

------
Someone
Some loose remarks:

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

------
nanoanderson
An important distinction here is that this is specifically a _programmer_ 's
problem solving sequence. It's not directed at "entrepreneurs," "UI
designers," "Information architects," or "Project Managers."

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.

------
lloeki
I'm impressed how up the list "google" is and down/middle the list "think" is.
How are you supposed to construct the query/question supposed to return
results relevant to your problem, let alone recognize you found something
relevant if you did not think about it beforehand? The most important part in
finding a solution to a problem is actually asking the right question, and
that requires quite some thought.

------
giberson
1\. Google 2\. Coworker 3\. RTFM 4\. Think

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.

------
yoshiks
While you can ask a good question or find good keyword for google, I think it
be ok to use google or asking at SO, anyway. You need to think what is the
best way to express your issue, and if you succeed, you are already 90%
solving that. And if you use google, you don't have to bother others so many
times...

------
nicpottier
Mine is simpler:

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. :)

------
Deestan
> should it be like this?

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.

~~~
fogus

        gets a good understanding of the problem
    

I'm skeptical that sites like SO or Quora foster understanding in in all but
the rarest of instances.

~~~
Deestan
If the programmer can't acceptable understand the issue at step N, he will
move to step N+1.

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

~~~
fogus

        well-written instruction material
    

Indeed they sometimes do. Most other times they contain the answers or worse
yet, the wrong answers.

~~~
Deestan
Always a risk. But so what? Goto N+1

------
grigy
For me it is:

1\. Google

2\. RTFM

3\. Think

4\. Coworkers

5\. StackOverflow

------
neutronicus
I find that what's out there on google tends to catch edge cases that my
cursory bit of thought leaves out - especially when I take the union of
several results.

------
beaumartinez
Reminds me of "The evolution of a Python programmer"
<http://gist.github.com/289467>

------
Jencha
This sequence helps not to: 1\. Reinvent the wheel

------
d0m
Also, Google and stackoverflow are mostly in the same step for me as I usually
only go on stackoverflow indrectly by google.

------
perlgeek
I do try the fine manual before googling. When working with CPAN modules I'm
often rather successful with that approach.

