3 ms·
At the beginning of my career I always choose fun names and was strongly in the camp of having fun names to identify better with my projects. After a few years
by dewey 4y ago
At the beginning of my career I always choose fun names and was strongly in the camp of having fun names to identify better with my projects.
After a few years, a growing number of services and branching out a bit more into infrastructure I came to the realization that this isn't the best choice and I'm fully in support of boring descriptive names now.
Our services are now called scraper, proxy-manager, webrouter. This makes it a lot easier to see dependencies, figure out what an alert is for or track down issues in a large micro-service architecture where you are not always sure what a service is used for.
- stevebmark 4y agoAfter a few more years where you have to scale these systems and redesign what services do and create competing ones that exist in parallel, you may find yourself back in support of non-descriptive names.
- pbreit 4y agoPremature optimization....
- stevebmark 4y agoMaybe, except there's not much downside. You also save significant time, because engineers trying to come up with the name of a service can be a drawn out and painful exercise, especially if it's a new service where you won't know its full responsibilities and boundaries until it's been used and built on for a significant time in production. I've seen so much time wasted with engineers trying to name services descriptively, especially when a similar service already exists.
- afiori 4y agoWhy not both? jellyfish-scraper, cantor-proxy-manager, pluto-webrouter
- dewey 4y agoSounds like something that's very easy to tweak once you get to a scale where it actually matters, until then I'll stick to boring descriptive names.
- afiori 4y agoPersonally I think I would go with a identity vs function distinction: a cog in an engine does not need a unique name, the entire car can benefit from one.