"Descriptive" names like in the article might not be a good fit, because they're just badly chosen and sometimes lie to you. I'd argue that actually descriptiv

"Descriptive" names like in the article might not be a good fit, because they're just badly chosen and sometimes lie to you. I'd argue that actually descriptive names aren't the worst thing ever, I wouldn't mind seeing a project/source code repo named "Client Bill PDF Generator" as long as the name on the tin actually matches what's inside of it. Of course, that implies that in the case of scope creep you should be able to change it as necessary. What this avoids is the problem of not needing a glossary to figure out what "Shelob" is supposed to be in a list of 50 different services, though I guess if you wanted to go for something fun, might as well throw them together: "Shelob: Client Bill PDF Generator". It's kind of how I approach naming my homelab servers/saving SSH sessions, a randomly chosen hostname comes first, but what it actually does is appended to the connection name/monitoring dashboard name - mostly because what I use the servers for might change so often, that this is one of the use cases where "fun" names make sense. Actually, Dylan Beattie once described why "fun" names might make sense, in a conference talk called "Life, Liberty and the Pursuit of APIness : The Secret to Happy Code", though it also touched upon other aspects of development. Here's the video timestamp for the problem situation: https://youtu.be/BIkXid_pBiY?t=769 https://youtu.be/BIkXid_pBiY?t=769 Here's the video timestamp for the proposed solution: https://youtu.be/BIkXid_pBiY?t=946 https://youtu.be/BIkXid_pBiY?t=946 The argument went along the lines of "by giving it a name, you cut out a lot of the noise". Curious, I can kind of understand that point of view, even though I'm not inclined to fully agree with it.