Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; his 9-to-5 home is at the startup he founded, Tilde Inc.. There he works on Skylight, the smart profiler for Rails, and does Ember.js consulting. He is best known for his open source work, which also includes Thor and Handlebars. He travels the world doing open source evangelism and web standards work.

The Blind Men and the Elephant: A Story of Noobs

If you will indulge me, I’d like to paraphrase a familiar tale:

Once upon a time, deep in the forest, there was a tribe of elephant curators. The elders of this tribe kept sophisticated, detailed notes about the proper care and feeding of elephants, and the villagers tended to follow along.

Eventually, they dedicated a large section of the local library to books and articles on the care and feeding of elephants.

One day, a group of blind nomads appeared in the village. Each of the blind men went to greet the villagers, and were met with welcomes. Wanting to be helpful, they walked over to one of the elephants and tried to learn about it.

The first man, who stood next to the elephant’s tail said, “I feel a snake”.

The second, who stood next to the elephant’s leg said, “I feel a tree trunk”.

And so on.

One of the group of nomads, who thought he felt a snake, went to the elders of the village and asked, “I would like to help. How can I feed this creature?”

The elder replied: “Sir, if you can’t be bothered to search the library for information on the care and feeding of elephants, surely you are wasting our time”.

Years passed and after a grueling series of trials, the blind men became integrated into the culture, becoming some of the most successful at caring for the elephants.

Eventually, another group of blind nomads appeared. The entire village, including the original group, proceeded to berate the new travelers. “We’ve spent quite a bit of time putting together a section of the library about how to care for these animals. You are wasting our time”.

Of course, the travelers did not know the creatures were elephants, and so they entered the library, searching for books on feeding snakes and caring for trees.

Eventually, an elderly blind man, of the original group stood up and said: “Have we forgotten than we, too, started in this confused state. We should help these travelers and perhaps they will become as wise and helpful as we became”.

To many participants in open source communities, this is a familiar tale. When a developer first comes across an open source project, either to use it in a project or to help, he is like a blind man feeling an elephant.

It’s easy to spit out “” or RTFM, but in truth, these beginners barely know where to look. All too often, we (open source leaders) assume that if someone couldn’t figure out the right search term on Google, they can never become a viable community member.

When I first started working on Rails, I distinctly remember not knowing what the request method in Rails controllers was. To some degree, this could be attributed to its exclusion in, but some judicious Googling turned up the ActionController::Request class. Writing this post years later, the request method still does not reside in the API docs, but I found the Request documentation in seconds.

The problem is that a new developer simply has no conceptual model for the problem at all. In most cases, the “noob” can stare at “the f***ing manual” all day and simply fail to find something staring him in the face. Importantly, this does not reflect a failing on the part of the new developer. Virtually everyone I know who worked their way from noob to senior Rails developer starting feeling around the elephant.

As open source leaders, if we are interested in growing our communities, we should treat new developers as confused people with real potential. That’s not to say that sinking dozens of hours down a black hole is a good use of time. On the other hand, the mismatch between how we think about problems once we become experienced and the way we feel around like a blind man when getting started makes the experience of getting started with an open source project far more painful than it needs to be.

40 Responses to “The Blind Men and the Elephant: A Story of Noobs”

Thanks for this! I’m new at Rails also – it’s good to know that a Rails guru like you went through something like this also :)

Also relevant:

Thank you so much for this post. People forgetting their noobish “roots” has lead to much counterproductive rudeness.

Fantastic piece Yehuda – completely agree (being a Rails nube myself!).

The questions from newbies are very valuable. Very often the questions are an indication that the software/application is not intuitive enough to use easily.

bad analogy, if they were blind they couldn’t read the books (unless they were in written in blind-nomad-braille).

blind is a poor analogy to noob, because a blind person can’t learn to not be blind.

Thanks a lot, a really nice article. This actually makes me want to learn Rails.

Great post. and encouraging.

I think this is particularly difficult for Rails, because there are side-effects everywhere. There’s no way to know how special environment.rb is from looking at the directory structure. And how would you know that models that live /app/models in correctly named files are automatically loaded?

The analogy to the elephant is perfect because you can stare at a view for hours and never be able to understand how it connects to the controllers, models, routes and so-on.

For better or for worse, with a language like PHP, you start at the top of your .php file and end at the bottom, and everything happens in between. If exploring a Rails app is like feeling an elephant, exploring a PHP app is more like finding your way back through underwater caves by re-coiling your rope.

Or something.

Some community members may shout the RTFM but you put your feet on noob shoes and do the other.:)

@poor analogy,

If that’s not a joke, whew, I think you’re missing just a tad bit of what Yehuda was trying to say.


Well said. I still sometimes feel a bit…hesitant…to ask about something I worry might be obvious, “easy” to grasp, or well known to others besides myself, and I’ve been working with Ruby, Rails, Merb and other techs for several years now.

I try to help even the ‘simplest’ question in #rubyonrails when I can, and keep up the great community feel we had in #merb . Remember people: it may be obvious to you, but hardly anything can be more damaging and discouraging to someone starting down a new road than some arrogant developer saying “OMFG IT’S OBVIOUSLY BECAUSE ITS A PRIVATE METHOD, NOT PROTECTED”.

When I started with Rails, the toughest part for me was learning how to express what I wanted to do. I knew the effect I wanted to create due to pervious experience (in Java, PHP, whatever) but I didn’t know how to write it in Rails.

I think learning the vocabulary is a big part of learning a new language or framework, and it’s tough to pick up without some kind of “rosetta stone”. I’m still sometimes frustrated with methods that are #nodoc’d in the Rails source and end up reading the code to learn how they work.

Thanks, i’m really happy to read this post. i feel once more , confident and welcome in the rails community. i am very sensitive to those values. I’m touched that you can keep this care for people when your talent could have focus all your attention to your own software and production.

you made my day katz.

Yeah, u r absolutely right (Y)

@wycats, how about YOU starting with NOT treating noob contributors with indifference?

Excellent analogy. I have often wondered if this is a problem that is only felt in the IT development field? Do medical professionals exhibit the same level of “RTFM” that is commonplace in our industry?

@artemave my sincere apologies. I had been communicating with Rizwan on this, and while it does seem that my comments got through, I definitely should have jumped in on that thread. I’d also note that the thread was brought up this evening in Campfire (prior to my post) and we’re looking at it for inclusion in the next beta release.

Thanks for your contribution; I personally have long wanted this feature, but it turned out to be fairly complex, and it looks like you powered through and got the job done. Many thanks.

A quick search in wikipedia reveals that the author raped, oops I mean paraphrase, the original story get his poorly written point across:

Stephanie Meyer would be proud.

I can’t decide which is more idiotic, this post or the myriads of blind praises.

The search for answers is much more important than the actual answers. Noob developers who are spoon-fed answers instead of researching, digesting and understanding answers causes software engineering to be like diet fads.

@tester, I don’t care where the story comes from or if Yehuda changed it or not, at least it enlightens the community about something (in this case, how to receive a noob better) where, on the other hand, your comment wouldn’t enlighten anyone, anywhere by being vulgar.

Obviously, there is a mid-term between giving answer to people and let them search for it, which is what we should aim, but, since your community is much more biased towards letting them search for it, Yehuda post is handy. If someday, we are giving people too many answers, you can write a blog post.

You’re right, of course, that we’ve all been there :)

It can get frustrating sometimes, however – with a bit of patience, googling, logic and code-reading, it’s not hard to figure out where things come from.

A question from a new developer about that semantics of some function, giving a bit of background about what they want to achieve, isn’t going to annoy anyone. It’s the “I want to post messages to twitter can you tell me how” questions that rub people up the wrong way, and maybe give the wrong impression sometimes.

@AaronBush I’m pretty sure that there’s a level of that in every industry. If I asked a group of builders why the ceiling keeps collapsing when I hadn’t yet built the walls, or a mechanic for a blow-by-blow guide on stripping down my car’s engine, I wouldn’t expect a polite response!


Where do you draw the line, though? At what point is it better for the noob to have the answer spelled out versus being nudged in the direction of If a noob asks, “how do I do X with Y” and the top hit for X Y is the right answer, is it really helping the noob *not* to show him that he could have searched for it and found the answer himself?

@José Valim,
It takes a child to point out the Emperor has no clothes. Cynicism works best when all sheeps are aaaaagreeing with each other.

1. Open source is about scratching an itch. When a noob asks about an open source project, the resource is already in front of him. It’s akin to asking a teacher for a definition of a word when the dictionary is smacking them in the face.

2. Learning is more important than answers. Why do you think specialist medical degree are so difficult? It weeds out those “noob” that are too impatient to learn. My “community” has the same bias towards searching as university are bias towards learning.

3. If manual cannot tell you what you want to know, then you lack enough research or the manual is badly written. Looking at the ActiveRecord mess, I could see the noob’s dilema.

4. This is a poorly written post. In order to make a point you need to make a sound argument. Having an bad analogy makes the argument weak. Therefore the argument serves no purpose other than being circle-jerk content.

However, if this is nothing more than a Dr. Phil group-hug moment, you can continue to bath amongst your drivel.

One interesting point I want to mention is that when you come to a new open source project you can read the code, the documentation and the comments, but one missing points is that there are no references where you can find why this code was written, what problems are solved and what design decisions are made.

I find this information to be very valuable for the ones that just step into the project, because the difference between the experienced one and the one just stepping into the project is in exactly that knowledge – the experience one knows how the project have evolved and why.

Sharing that knowledge will help people who are not good coders to understand the design process behind the actual code they see.

@José Valim and @tester, you guys are parts of the same elephant. Counterparts though.

Thanks for articulating this. Nice post.

“Have we forgotten than we” should be “Have we forgotten that we”.

I assume you’re writing this because some people are being n00b-unfriendly. Is this a problem in Stack Overflow, or elsewhere on the net?

Sometimes we get questions because something is hard to google and we give the googleable term for it, for example !!foo

I totally disagree. @larrytheliquid mentioned the Dreyfus model. I have to say that people who follow this model in learning new skills will never be good coders. To quote Wikipedia:

> 1 Novice
> * rigid adherence to rules
> * no discretional judgment

Sounds like someone who has no curiosity, is afraid of playing with stuff because it might break something, or is just plain lazy and non-self-reliant and keeps asking for teh codes. These people don’t deserve even a patronizing Google/Wikipedia/API link in reply. They should just be ignored.

I think this cuts both ways: experienced developers need to be more courteous and helpful in answering noob questions, and those asking questions should spend some time digging into the problem–i.e. reading the source code, debugging into it, etc.

@no longer a noob: As much as possible, I think we should aim to help the noobs learn the answers, and not simply feed them the answers. Rather than just telling them the answer, maybe you can ask some leading questions that can help the person understand the “why” and the “how”, and not simply the “what”.

Yehuda is not saying anything earth shattering here but its still nice to hear it being said. IMO attitude is a big factor in the success of any software project. Its even more important in something that involves volunteer contributions.

Its been my personal experience that the so called “noob” often ends up making extremely valuable contributions after they are shown the way. I am also fond of saying that “some people cannot be helped.” Its a two way street and if the noob is not receptive to new ideas or listening to your explanations then you are wasting your time.

Thanks for encouraging people to maintain the proper attitude. It also appears that you have inspired several so called noobs with your own noob origin story.

I certainly agree with Yehuda’s summary of the difficulties faced by noobs, though I think maybe there is a little more to the underlying cause than is evident in the elephant story (Evgeni’s comments start to get at the issue) …

I think part of the problem has to do with the balance of skills amongst people working on open source. I don’t mean the level of skill, which of course is inevitably very broad, but rather the kinds of skills being brought to bear. My impression is that most people involved in open source are essentially (surprise, surprise) coders, which of course is fundamentally essential. But not all software developers have the instincts, inclination or background to think about software from an architectural perspective and even fewer get excited about the idea of writing about architecture.

So though there may be an ocean of blog articles explaining how to solve every imaginable coding problem, there is very little documentation that attempts to describe the overall design of many software projects. And without some view of the architecture of these complex systems, it becomes much much harder to penetrate the code itself.

I would suggest that those debating how much aid should be given to novices read about Vygotsky’s Zone of Proximal Development and Social Constructivism.

“Teach a man to fish” isn’t just exclusionary; it’s self-defeating. It’s the Law of Emergent Fish. You might be congratulating yourself for being such a long-term thinker, but guess what the NEXT person who tries to Google it will find?

Your suggestion that they try Googling.

I am from java world and i learn more learning with reading the source code than from reading the doc files. In rails and with many gems it is hard to fas read the source, because the docs only display not the full source but only small method source code. Linking the original code to the docs is just a small link but helps very well to learn it. Also in most ide for rails i dont find out how to open the source code of a gem/railspart with just a click like in java ide i am missing.

To change all the ide is hard – but to change the doc gerator to also show the full source code its a smaller change i think.

Yes. Dear god, yes, I completely agree with this. We were all noobs once and we should spread our knowledge to those without it so that they may spread it to those also without it.

Great post. It often takes very little time to point a “noob” in the right direction. PHP, for instance, has so many built in functions, but if you never know about them in the first place, you often end up reinventing the wheel.

@arno – RubyMine’s click-through-to-declaration and debugger has gotten pretty good in the latest releases, including gems and non-native Ruby language code. If you learn best by reading source (which is a good thing!), I’d recommend trying RubyMine.

Excellent post. Well said, Yehuda.

Although, I find it a little sad that we have to remind each other to behave with civility.

I think the comments have gotten a little off-track in debating whether or not you should help noobs, or in what situations should you help them vs. letting them figure things out for themselves. The most important message of this post is, whether you choose to help them or not, don’t be a jerk about it.

Exactly what do you believe is the easiest weblog software to make use of for someone that has a quite restricted understanding of systems?

Leave a Reply