Soft skill: naming things
There is a somewhat arbitrary separation in tech between soft and hard skills.
Hard skills are technical skills. Knowing a programming language. Understanding a protocol. Experience with a specific piece of software. Which is all good and nice, of course. Most of us working in tech enjoy these "hard skills", or we would work on something else, right?
Soft skills is everything else. Knowing how to negotiate your sallary? Soft. Being good managing your tickets? Soft. Communication? Presentation of knowledge? Knowledge sharing? Soft, soft, soft.
See more about soft skills here.
Today's soft skill?
Which is, of course, one of the famous two hard things in computer science1
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton
This is an underrated skill. Advertisers and wizards know a good name is a big deal, and once a name is applied, getting rid of it is very difficult, so it's a good idea to try to get it right (or at least not horribly wrong) the first time.
Know your audience
You will see here rules. They are all meant to be broken on occasion. Which ones can be broken and which ones can't?
If it's an internal tool in a company where everyone speaks english, then you don't need to spend much effort making sure it doesn't mean "testicles" in german (it's Hoden, BTW)
If it's a niche open source tool then the rule against obscure jokes doesn't really apply because there's tradition.
OTOH calling things by offensive names with intent is probably always a bad idea.
Where do you draw the line? Well, if I could give you an algorithm for that it would not be a soft skill, would it?
Rules For Names
So, what's a good name?
It's not a common word.
Make it easy to google. Please. Make it be something that's not already a much larger thing. Do not call your bigint library "Grande". Nobody will be able to ask about it without being flooded by links about tiny singers and large (not not the largest) coffees.
So, if you can't come up with a very uncommon word ... go to other languages. Go to unusual languages. That, plus context, will help.
It's not a "bad word" in another language.
Yeah, that sucks. But hey, it's also hard to figure out in advance. At least check English Spanish and Cantonese ?
There is a reason why the Mitsubishi Pajero is called "Montero" in spanish-speaking countries.
It's not an obscure joke.
Python is called Python because of Monty Python. Which means the place where you downloaded packages was called "The Cheese Shop". And the format for the packages was called a wheel (as in "a wheel of cheese").
Obscure jokes have a tendency to encourage secondary, more obscure jokes to the point of incoherence. Try explaining "why is this called a wheel?".
Recursive acronyms count as obscure jokes. Yes.
Make it memorable and descriptive.
Not "Object Adapter Library"
Not "Language Extension Package"
Yes, those names are "descriptive" in a dry, totally uninformative way, but I am going to forget them in 30 seconds and I just made them up right now.
So, use an arbitrary, memorable name. If it works as a menmotechnic for what the thing does, better. Good examples:
SQLAlchemy: memorable. It's about SQL. It suggest complication and probably some supernatural intervention will be necessary.
Ruby on Rails: memorable. It's about Ruby. Ok, so it's not about trains, but "on rails" has metaphorical meaning.
And yes, this rule 65% of the time collides with "not an obscure joke".
Make it short
"Llanfairpwll-gwyngyllgogerychwyrndrob-wllllantysiliogogogoch Enterprise Edition" is bad.
Don't make it too short
"C" is bad (it was good in the 70s!).
Make it clear in context
Naming things is not only about naming software or things, it's also about variables, classes, and identifiers in code in general.
- "i" is often bad
- "strFirstName" is always bad
- "data" is always really bad
- "ObjectAdapterInterface" is making my eyes bleed.
A name is not a description. So, "strFirstName" is trying to describe "it's a string with the first name in it". What else is it going to be? A boolean? Do you call your pet "dogFido"?
But a name has to be a name. If you call your dog "dog", then "data" and "i" will look good to you.
And a name is not a DNA test. You don't need to describe the ancestry of things, just say what they are. A glass is not a DrinkingWaterContainer. It's a glass. 2
Name things what they are, or something that lets you identify them. I know, radical.
You didn't expect me to solve one of the hard problems, did you? No, I won't. These are just, like I said, rules meant to be broken. But you need to break them consciously.
For example, I am naming a project of mine CobraPy. because it's an 80s-style retro thing, and in the 80s Karate Kid was cool, and in Karate Kid there's Cobra Kai, and that sort of sounds like CobraPy and Py is for Python, and Cobras are also snakes.
But I named it that on purpose.
Which is the source of an infinite number of jokes. ↩
See This comic ↩