I’ve been told multiple times in multiple jobs that I’m good at naming things, and I love whimsical names. A couple rules I’ve internalized are:

- if it’s hard to name, that’s a good sign that you haven’t clearly delineated use case or set of responsibilities for the thing

- best case for a name is that it’s weird and whimsical on first encounter. Then when somebody tells you the meaning/backstory for the name it reveals some deeper meaning/history that makes it really memorable and cements it in your mind

- the single best tech naming thing I’ve encountered (I didn’t come up with it) was the A/B testing team at Spotify naming themselves “ABBA”

> I’ve been told multiple times in multiple jobs that I’m good at naming things, and I love whimsical names.

As long as you're naming products and features, rather than variables.

oh yeah, definitely. for variables its best to exclusively use obscure unicode.

The winner takes it all!

God this article is 10000% better than the posted one. This is great:

> Names should not describe what you currently think the thing you’re naming is for. Imagine naming your newborn child "Doctor", or "SupportsMeInMyOldAge". Poor kid.

I totally agree with this, and will add that another benefit of whimsical names is discoverability. If your project is named plugin-update-checker and I want to find documentation on it, it's likely going to be buried in a bunch of other irrelevant search results about plugin update checkers in general. If it was called SocketToMe instead, I'm going to find much better search results.

Go.

I suppose it depends on your goals, but that scope restraint can be a good thing.

Do one thing, do it well, and while you're at it call yourself by the thing you do so you remember that's what you ought to be doing. A bit wordy for unix but you get the idea.