3 ms·

I've learned to really loathe 'fun' names for projects (especially internal-only projects). it really just obscures whatever the project is intended to do. AW

by chrsig 5y ago

I've learned to really loathe 'fun' names for projects (especially internal-only projects). it really just obscures whatever the project is intended to do. AWS is probably the worst in this regard...so many services with names that give no indication about what the service actually does.

tayo42 5y ago
I can't pick a side on this. I agree with you in general but also it's nice to be reminded that there's a human and personal element to things sometimes. I normally name what ever I'm working on to be clear and boring though.
- chrsig 5y ago
  I understand the distaste for the stiffness of descriptive names...but I've found that over time trying to explain why a project has a clever name, or what it really does, to be quite arduous. And usually not too long after I've coined a fun name for a project, I wind up feeling like it's cringy, and start to loathe when other people talk about it.
arantius 5y ago
I have the opposite position. I feel that meaningless (especially if there can be a subtle fun part) names are the only valid thing for internal projects. I've worked on so many that A) are difficult to impossible to name "descriptively" and B) over time, shifted away from their original purpose. Meaning the long and awkward "descriptive" name becomes a lie over time. But the "code" name has no meaning, so it doesn't become wrong, you just need to maybe re-learn the meaning of the otherwise meaningless word. See also: How do you descriptively describe the replacement/rewrite that does the exact same thing, but exists in some form while the other one does, also?
- chrsig 5y ago
  Interesting. I don't experience much of what you're describing -- especially B. How often is it that you have a service that drastically differs in purpose from it's original intent? Can you give an example of how that comes about?

by chrsig 5y ago

tayo42 5y ago

I can't pick a side on this. I agree with you in general but also it's nice to be reminded that there's a human and personal element to things sometimes. I normally name what ever I'm working on to be clear and boring though.

chrsig 5y ago
I understand the distaste for the stiffness of descriptive names...but I've found that over time trying to explain why a project has a clever name, or what it really does, to be quite arduous. And usually not too long after I've coined a fun name for a project, I wind up feeling like it's cringy, and start to loathe when other people talk about it.

arantius 5y ago

I have the opposite position. I feel that meaningless (especially if there can be a subtle fun part) names are the only valid thing for internal projects. I've worked on so many that A) are difficult to impossible to name "descriptively" and B) over time, shifted away from their original purpose. Meaning the long and awkward "descriptive" name becomes a lie over time. But the "code" name has no meaning, so it doesn't become wrong, you just need to maybe re-learn the meaning of the otherwise meaningless word. See also: How do you descriptively describe the replacement/rewrite that does the exact same thing, but exists in some form while the other one does, also?

chrsig 5y ago
Interesting. I don't experience much of what you're describing -- especially B. How often is it that you have a service that drastically differs in purpose from it's original intent? Can you give an example of how that comes about?