The Blind Men and the Elephant: A Story of Noobs | Hacker News Reader

The Blind Men and the Elephant: A Story of Noobs

yehudakatz.com

56 pointswycats12 comments

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.

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.

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.

He's talking about it from the maintainer's perspective. He's saying that the noob questions are valuable feedback to what's confusing about the project.

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.

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.

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.

blocks and lambdas in Ruby?

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

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

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

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.

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.

Reply on news.ycombinator.com