

The Blind Men and the Elephant: A Story of Noobs - wycats
http://yehudakatz.com/2010/02/09/the-blind-men-and-the-elephant-a-story-of-noobs/

======
pbhjpbhj
You can tell when someone asks a question whether they have bothered to try to
get an answer by their own effort or not. Even if they haven't tried a
different way you can usually tell if they are trying to provide you with help
to give them the answer.

Instead of "how can I feed this creature" the blind man should say "how can I
feed this creature, it appears to be a snake and my research has shown they
eat mice, should I feed it mice?". One knows then what has been tried (or is
being suggested), what assumptions are being made and can better aid them.

------
jwhite
I'm starting out in Ruby the last couple of months, but I've done a lot of
Python, among other things. I've read other people criticizing the poor
standard of documentation of some parts of Ruby and Ruby libraries, and from
my recent experiences, I can sympathize. But as a maintainer of an open source
library, I can also sympathize with the feeling that documentation always
seems like a lower priority compared with new features.

Recently I've been getting a lot of user support requests that have made me
realize I have to lift my own game when it comes to documentation. It is worth
remembering that the 'Laziness' component of 'Laziness, Impatience, Hubris',
includes a healthy dose of documentation:

"Laziness: The quality that makes you go to great effort to reduce overall
energy expenditure. It makes you write labor-saving programs that other people
will find useful, and document what you wrote so you don't have to answer so
many questions about it. Hence, the first great virtue of a programmer."

From <http://c2.com/cgi/wiki?LazinessImpatienceHubris>, quoting Larry Wall.

I found that to be good motivation.

EDIT: Also, API documentation isn't enough for new users. As the article
points out, users need to be taught the basic concepts to know they are
dealing with an elephant, not a snake. Without the basics it is hard to ask
intelligent questions.

------
melling
This is a solved problem.

<http://stackoverflow.com>

Pick your topic, search for questions, and ask them. Scala, Clojure, Squeak,
Rails...

<http://stackoverflow.com/questions/tagged/scala>
<http://stackoverflow.com/questions/tagged/clojure>
<http://stackoverflow.com/questions/tagged/squeak>
<http://stackoverflow.com/questions/tagged/ruby-on-rails>

These days it's much easier to go from noob to expert in whatever topic, even
if the topic is a bit esoteric. The great thing is that you're throwing down
breadcrumbs for the next guy.

~~~
patio11
A problem with learning difficult topics, and Rails apparently is one of them
for a lot of people (try coming to it without a background in web development
or OOP, for example), is that you don't even know what questions to ask.

Stack Overflow is _amazing_ for when you can concisely describe the exact
issue you're having in such a manner that someone else can Google it for you.
It is less amazing when you lack the mental framework to identify where the
gap in your understanding probably is.

I think this is the cause of a lot of the complaining about "magic" in Rails.
It isn't magic when it is working, it is only magic when it breaks. Then
people often find, whoops, they don't have a good enough understanding of what
is happening to diagnose what probably went wrong.

------
waratuman
This is so true, yet when other people ask me for help it is so easy to say
"read the api docs" even though I have gone through the same process and
frustration.

The whole process of learned a new tool or language requires a lot of work.
Sometimes the people who are new to it will give up because they simply were
unable to understand some small issue. I suppose it is up to both parties, the
leaders and the new developer. The leader has to encourage and support while
the new developer must be willing to work hard and not give up.

------
raasdnil
Good point. We do need to remember our own confusions when starting with
rails, I remember looking at lambda and being totally confused, took me months
to really grok blocks and lambda's in Rails.

Being worried about asking for fear of getting lmgtfy'd is not conducive to
expanding a community.

~~~
hackoder
blocks and lambdas in Ruby?

------
ubernostrum
Of course, there's a flip side to this:

<http://slash7.com/2006/12/22/vampires/>

~~~
wycats
I'm pretty sure the help vampire phenomenon is an example of the lmgtfy
phenomenon and not a real problem (except in rare cases)

~~~
ubernostrum
I've personally dealt with "help vampires"; they're not rare, and they tend
(in my experience) to fall into two groups:

1\. People whose attitude is "I will remain as ignorant of as many things as
possible for as long as possible". Try to point them to documentation which
covers broad/fundamental concepts, or explain them yourself, and the reply
you'll get is "I don't need to know all that, I just need to know how to do
X". Learning enough to find your own way is, I've been told, simply a massive
waste of time. Of course, later they'll be back with "now I need to know how
to do Y", and again stubbornly insisting that there's no need to learn
generalities...

2\. "plz send me the code" -- people who won't even learn the specifics of a
task at hand, but just keep badgering until someone hands them fully-working
code. Point them at appropriate documentation and, nine times out of ten, they
copy/paste the first code sample on the page and come back to say it didn't
work.

I see, on average, about one or two of these every day on IRC and mailing
lists. Unfortunately, these behaviors tend to be successful in the short term:
sooner or later _someone_ will step up and give the vampire what he wants, and
the cycle will start all over again. Long-term, I don't know; I tend to be
liberal with the /ignore, and I don't keep track of whether these people later
evolve away from these behaviors.

------
cturner
When I'm new to something and get that feeling of having hit a barrier, I try
to remember to "go broad before you go deep".

It's too easy to feel the tail of the elephant, think it's a snake, and then
go off based on that assumption and waste enormous time. You have to avoid
doing that. Make yourself consider assumptions before you work form them.

One way to do this is to force yourself to write out a list of ten strategies
for helping to solve whatever problem you're stuck on. The ten-ways works for
most things in life. Five isn't enough - you have to force yourself to really
think.

