Naming Your Stuff

Names are hard, especially for a framework or library. A good name is memorable, and can be a shot in the arm in terms of discoverability. Finding a good name is nebulous, and too often falls into the I’ll-know-it-when-I-see-it category. But a bad name is easier to define. The biggest sin of bad names is that they are impossible to find answers when you run into questions.

I don’t like to throw rocks at somebody else’s hard work, but I think it’s been enough time that I can gently criticize the name of the Prototype JavaScript library¹. Why was this a bad name? Well, what do you do when you run into a problem that isn’t quickly found in the official documentation? Search for it on Google. Now, the term “prototype” is a core part of the JavaScript language, which meant that every single search result for “prototype X”, “JavaScript prototype X”, “prototype js X” or any other combination only referred to dealing with prototypal inheritance in JavaScript.

You may be the biggest fan of both The Simpsons and Ruby. Don’t name your library “Homer”. Again, what happens if someone runs into a problem when using Homer? They’re going to try to search for “homer fix json serialization” and get a bunch of funnier Simpsons quotes. Your JSON parsing library is never going to be more popular than Mr. Simpson, so please, pick something else.

Common words aren’t necessarily bad. Backbone, Underscore, Rails, node, and express are all fairly common English words, but none of them are common enough to pollute search results. Spend a few minutes searching around before putting together your splash page.

---

• ← Friction and Teams
• Podcasts I Listen to (July 2014) →