5 ms·

I believe strongly in this counterargument: https://medium.com/better-programming/software-component-names-should-be-whimsical-and-cryptic-ca260b013de0 https:/

by kixiQu 10mo ago

I believe strongly in this counterargument: https://medium.com/better-programming/software-component-names-should-be-whimsical-and-cryptic-ca260b013de0 https://medium.com/better-programming/software-component-nam... Small summary: external identifiers are hard to change, so projects will evolve such that they are not accurately descriptive after time. (Less discussed there, but: In a complex or decentralized ecosystem, it's also the case that you come across many "X Manager"/"X Service"/"X State Manager"/"X Workflow Service" simultaneously, and then have to rely on a lot of thick context to know what the distinctions are)

pksebben 10mo ago
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.
parpfish 10mo ago
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”
- mbg721 10mo ago
  The winner takes it all!
- zahlman 10mo ago
  > 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.
  - parpfish 10mo ago
    oh yeah, definitely. for variables its best to exclusively use obscure unicode.
deleted 10mo ago
[deleted]
deleted 10mo ago
[deleted]
deleted 10mo ago
[deleted]
tomnicholas1 10mo ago
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.
Umofomia 10mo ago
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.
- tstenner 10mo ago
  Go.

by kixiQu 10mo ago

pksebben 10mo ago

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.

parpfish 10mo ago

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”

mbg721 10mo ago
The winner takes it all!
zahlman 10mo ago
> 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.
- parpfish 10mo ago
  oh yeah, definitely. for variables its best to exclusively use obscure unicode.

deleted 10mo ago

[deleted]

deleted 10mo ago

[deleted]

deleted 10mo ago

[deleted]

tomnicholas1 10mo ago

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.

Umofomia 10mo ago

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.

tstenner 10mo ago
Go.