Well, it's corrected coffee, which matches their intention and general java/beans/jar theme. I kinda like it.

https://en.wikipedia.org/wiki/Caff%C3%A8_corretto

TIL you 'correct' coffee by adding alcohol.

I'll take names over alphabet soup. My EBS EC2 machines are not playing nicely with ELB (but my EFS ones are), I think it might be to do with EMR, or maybe EKS.

You could always say: "My elastic block service elastic cloud compute machines are not playing nicely with elastic load balancers (but my elastic file system ones are), I think it might be to do with elastic map reduce, or maybe elastic kubernetes service." No soup.

You nailed it, I hate the tendency of english speakers, specially in tech, to use nonsense acronyms when it would be much easier and understandable to use the word itself, or at least part of it.

It feels like English should have a provision to factor out the word "elastic" in this case.

Just assume every word in the sentence is elastic.

"My elastic block service elastic cloud compute machines are not playing nicely with elastic load balancers (but my elastic file system ones are), I think it might be to do with elastic map reduce, or maybe elastic kubernetes service."

"My elastic services are not working. Cloud compute machines..."

> No soup.

Yeah, what you did is more like a porridge that makes you choke.

The problem is partly that AWS—sorry, Amazon Web Services—refer to their products like this in all their documentation and marketing. Using acronyms is great for brevity in communicating within closed environments (we use our own acronyms within our own office to refer to many things, including clients), but if you're product names so long-winded in the first place that you're acyronymizing them all publicly in your own materials you have a problem.

No way engineers will ever do this. We're far to use to TLAs and also, it's way too long. Having a simple, metaphorical brand name allows you to then build on top of that. Can you imagine if Java had instead been called WriteOnceRunAnywhereC++Alternate instead of java? Then, we'd have the writeoncerunanywhereC++alternate Virtual Machine

WORAC. I like it.

So much better.

so elastic!

That's a different company!

Everybody loves a good TLA!

I think you need some ECS in that mix as well...

Hmm interestingly they renamed that to Elastic Container Service. It used to be named kinda recursively as EC2 Container Service.

[0] https://aws.amazon.com/ecs/

[1] https://aws.amazon.com/about-aws/whats-new/2014/11/13/introd...

>would start using practical/self-explanatory names for their products

So like "Java" and "Swing"?

I’m honestly surprised they didn’t go with “Simple Java Service”. /s

Edit: Added sarcasm indicator

Probably because they don’t own the trademark on Java.

Within reason, you are actually allowed to use someone else's trademark for something like this provided your own trademark is the more prominent. So something like "Amazon Distribution for Java" would be fine.

Well, for one it's not a service...

Or something as Simple as Amazon JDK.

Unless JDK is trademarked to death by Oracle...

Funny, because I can rarely remember GCP's services yet AWS' I don't forget.

Speaking of, CoveffeJDK hasn't been taken yet.

I think you mean CovfefeJDK.

haha. Thanks

It's like they're trying to add an extra layer of stuff that must be learnt in order to use AWS. I have to wonder if it's intended to gear them toward being able to create AWS-specific exams & certifications.

I'd settle for properly written documentation.

I'm a long time AWS customer and I love AWS, but to be honest, the documentation is bad. I don't think they understand how to write for developers at all. It feels like they hired an army of Kevin Turvey clones.

I find that the structure of their documentation could use some work, but the actual language to be fairly good. And by good, I mean less bad when contrasted with most documentation.

To go off on a bit of a tangent, I'd prefer that documentation be split up into two parallel versions that are heavily linked but mostly separate:

- Code examples describing everyday usage

- Detailed API/system descriptions

AWS should do a better job on the former, although that'd be a massive amount of work for them at this point with little payoff. I find that I end up relying much more on Stack Overflow and even code from wrapper libraries to understand how to do relatively uncomplicated things with their API. In general, however, I'd prefer it that all documentation be more the former than the latter. I find that when I'm given everyday examples, that aren't hideously formatted on the webpage, I can get a better understanding much quicker and become far more productive.

Most documentation isn't good at either providing practical examples or actually explaining usage. I feel like there's a missing link between English-majors and software engineering; if there are English-majors who also understand programming, they should be paid handsomely to write documentation. But when do we ever see job postings for specialists in writing documentation? I've never seen such a job title.

it doesn’t matter when you have this many products. if you know the product, you will find or learn the name. if you don’t know the product, the name doesn’t matter

I'd argue it matters more when you have that many products because it takes a greater amount of mental mind games to remember what all the arbitrary names and acronyms refer to in terms of real world services.

It also makes discoverability harder. eg when you're already on AWS and you think "is there a service that does something like [insert problem]?"