231–240 of 339 posts
Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs assumes that that's as hard as the world gets. If all of your software components are constantly changing their scope, it indicates you are doing a bad job of producing an up-front system design. If your experience causes you to scoff at the concept of producing…
Earlier quoted context omitted.
But as products evolve, their boring names become misleading. At least with non-boring names you can re-define what they represent in your company.
Do products/components really evolve so much that the name frequently become outdated? Half the article is like, " There was a component called YamlParser, which is now a browser-based stable-diffusion renderer! "
They didn't change names, but their successors would get a new one.
Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs assumes that that's as hard as the world gets. If all of your software components are constantly changing their scope, it indicates you are doing a bad job of producing an up-front system design. If your experience causes you to scoff at the concept of producing…
In spite of that, when did "making a database product" count as not "hard?" Building a database isn't "real software engineering™?" Since when was building "authorization microservices" easy? In the simplest case, sure. But authorization in general is a huge problem space and I don't understand calling that "bs." Active Directory would like a word...
In a team ecosystem where you probably need to optimize for readability and ease of use, try to be simple and accurate and get used to refactoring. Making up random shit is the worst advice I can think of.
Earlier quoted context omitted.
I came here to write something similar. The article lists a few repos as examples of bad naming when the reality is, it’s examples of miss-naming. For a long long time I’ve convinced people to use literal names for things and not get creative. A BillingStatusService , as the author has cited, isn’t an example of a bad name. It’s an example of bad engineering that it does more than BillingStatus . Often times when peo…
> The article lists a few repos as examples of bad naming when the reality is, it’s examples of miss-naming I'd assume everyone here could at least agree that naming is hard. I don't think the article was attempting to explain how to name, but instead point out one potential pitfall when naming.
Naming things is also very important. Having some common language or way to refer to the various abstractions in the business is essential for basic teamwork. Even if the name is a cringetastic take on a comic book character. As long as everyone agrees on the string literal, you will be able to make forward progress.
If you aren't absolutely certain what something should be called (i.e. maybe you are prototyping a crazy new idea), just invent some crap to keep moving along. I've got a shitload of odds and ends in static classes simply named things like "Utility" and "Hack". When you aren't so invested in what something is called, I have found you are much more willing to get "creative" with it. Naming things can also start to imply some sort of structure, so keeping it flat like this helps reduce the cognitive load.
On the other hand, maybe you should consider more precise, deliberate naming if the business at hand is relatively stable and complex. Banking is a great example of a domain where very precise type names can make a huge difference in productivity. There is a gigantic difference between a "beneficial" owner and a "beneficiary". Applying reductive/creative naming schemes to this domain would likely cause more harm than good.
You can always rename stuff in the future. Even database schemas can be migrated over time without impacting live customers. You can even rename an entire company (i.e. Facebook => Meta).
Author used to build authorization microservices, and now works at a company making a database product. Once again, somebody who works on some web service bs assumes that that's as hard as the world gets. If all of your software components are constantly changing their scope, it indicates you are doing a bad job of producing an up-front system design. If your experience causes you to scoff at the concept of producing…
Quoted post unavailable.
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
Here's the video timestamp for the proposed solution: 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.
> Names should make you smile. Yes, you, specifically. You should get a dopamine hit whenever something you created comes up, even when it’s in a sentence like “Shelob has broken again.” Fun is one of the most important things there is. I'll never understand this mentality, where a silly project name is a source of "fun." I would never dare tell anyone what should be fun for them... except in this case, where I will…
https://www.youtube.com/watch?v=y8OnoxKotPQ
I'm completely with you that name choice is not necessarily where something needs to be fun, and most people don't realize that once you name something, it's probably around for 5-10 years whether you like it or not. Or if it succeeds or fails.
> See, the scope and purpose of something changes faster than its name can. There's your problem. Create libraries that aim to do one thing and do it well. Once you release your project and have users that depend on your code, you owe it to them to maintain it in the original scope. If you have an urge to change your project's scope so much that the name should change, create a new library with a better name instead.…
> Create libraries that aim to do one thing and do it well. That's nice and all, but once you combine that with giving them descriptive names, you're going to have a list of hard-to-distinguish projects like: - css-min - css-polyfill - css-inline-min - css-inline-polyfill - css-script-min - css-script-polyfill - etc. Good luck clarifying what you're talking about. And of course, people will start using acronyms for a…
What's hard to distinguish? These are projects that do something with CSS. If you don't need css, you skip them. If you need a polyfill, you only look at polyfill ones to see what you need.
Now, let's imagine your list is "creatively" named like
- shelob
- arcana
- custard
- escalope
- virtuocsso
- jester-css
- etc.
Ah yes, this is so much easier to distinguish, isn't it?