Yes, everywhere. You just need to look for it. See the following link, which has references to Apollo and MAWS.

https://blog.pragmaticengineer.com/amazon-notable-systems/

> I thought this sounded crazy, and it would be interesting if Amazon themselves didn’t even have what was being asked of us.

Amazon has multiple incantations of this. As legend would have it, AWS was an offshoot of Amazon's internal cloud infrastructure designed to monetize it to amortize their investment on bare metal infrastructure. They partitioned their networks for security reasons and for a few years their infrastructure evolved independently. Then AWS was a huge success and took a life of its own. Only relatively recently did Amazon started to push to drop their internal infrastructure to put all their eggs on AWS in general but serverless solutions in particular.

Irrelevant, as a) that's just your own personal and very subjective opinion, b) DDD is extensively documented as the one true way to write "good code", which means that by posting your comment you are unwittingly proving the point.

> However, the underlying ideas are not strongly married to object orientation and they fit quite nicely in a functional paradigm.

"Underlying ideas" means cherry-picking opinions that suit your fancy while ignoring those that don't.

The criticism on anemic domain models, which are elevated to the status of anti-pattern, is more than enough to reject any claim on how functional programming is compatible with DDD.

And that's perfectly fine. Not being DDD is not a flaw or a problem. It just means it's something other than DDD.

But the point that this proves is that there is no one true way of producing "good code". There is no single recipe. Anyone who makes this sort of claim is either both very naive and clueless, or is invested in enforcing personal tastes and opinions as laws of nature.

No. Your claim expresses a critical misunderstanding of the principle. It's desirable that a browser should be robust to support broken but still perfectly parceable HTML. Otherwise, it fails to be even useable when dealing with anything but perfectly compliant documents, which mind you means absolutely none whatsoever.

But just because a browser supports broken documents, that doesn't make them less broken. It just means that the severity of the issue is downgraded, and users of said browser have one less reason to migrate.

I don't think that's true at all. The whole point of the law is that your interfaces should be robust, and still accept input that might be nonconforming in some way but still be possible to validate.

The principle still states that if you cannot validate input, you should not accept it.

Why do you believe that?

Being liberal in what you accept doesn't mean you can't do input validation or you're forced to pass through unsupported parameters.

It's pretty obvious you validate the input that is relevant to your own case, you do not throw errors if you stumble upon input parameters you don't support, and then you ignore the irrelevant fields.

The law is "be conservative in what you send, be liberal in what you accept". The first one is pretty obvious.

How do you add cost to the entire ecosystem by only using the fields you need to use?

AWS. Because AWS reports close to $11B/quarter, which is over half Amazon's entire revenue, and AWS owns the cloud computing market, on which the whole world runs.

This. They also make it their point to send the message this particlar firing round is completely arbitrary and based on a vague hope that they somehow can automate their way out of the expected productivity hit, and that they enforce this cut in spite of stronger sales.

AWS is the cash cow. It owns between a third and half of the world's cloud computing market. Do you think it's hard for AWS to get financing?

Another factor, and perhaps the key factor, is that contrary to OP's extraordinary claim there is no such thing as objectively good code, or one single and true way of writing good code.

The crispest definition of "good code" is that it's not obviously bad code from a specific point of view. But points of view are also subjective.

Take for example domain-driven design. There are a myriad of books claiming it's an effective way to generate "good code". However, DDD has a strong object-oriented core, to the extent it's nearly a purist OO approach. But here we are, seeing claims that the core must be functional.

If OP's strong opinion on "good code" is so clear and obvious, why are there such critical disagreements at such a fundamental levels? Is everyone in the world wrong, and OP is the poor martyr that is cursed with being the only soul in the whole world who even knows what "good code" is?

Let's face it: the reason there is no such thing as "good code" is that opinionated people making claims such as OP's are actually passing off "good code" claims as proxy's for their own subjective and unverified personal taste. In a room full of developers, if you throw a rock at a random direction you're bound to hit one or two of these messiahs, and neither of them agrees on what good code is.

Hearing people like OP comment on "good code" is like hearing people comment on how their regional cuisine is the true definition of "good food".

I think you are talking out of ignorance and spite. Most of the services used by Amazon employees are internal services that may or may not be on par with the state of the art. Apparently a big chunk of Amazon doesn't even use AWS at all, and instead use proto-cloud computer services that are a throwback from the 90s take on cloud computing.

No. My definition is Amazon's actual organization chart as a holding. AWS is an independent first-level branch of direct reports of Andy Jassy, who was AWS's CEO before replacing Bezos. A similar branch is Worldwide Consumer, which groups what you think Amazon actually is, which means the online store, prime, books, devices, etc.

What do you think "Kindle" is? Is it a specific device? Is it Kindle for Web? Is it the Android or iPhone apps? Is it Kindle for Windows or Kindle for Mac? Among these, can you count how many are paid?

I think that's a simplistic view of the issue. At Amazon, each team owns at best specific features embedded in products. Some projects such as e-readers are there as loss leaders to support cash cows such as it's ebook market. From your simplistic opinion, Amazon would have cut zero employees from it's books organization as it's business is booming and it's a profit center. But that doesn't match reality.

Also note that you are making that unfounded claim while commenting on news that Amazon is going to focus it's firing round on HR. Is HR a profit center now?

> Events like this are when the teams not contributing to the bottom line are cleaned up.

Except that's bullshit. Amazon decimated teams by firing new arrivals and by transferring projects out of the US into Europe and Asia. This hasn't anything to do with efficiency or performance in mind.

Actually, they are. Perhaps what is causing your confusion is that other parts of Amazon, such as Ring or Rivian, are also separate companies, whereas parts such as Alexa and Amazon Music aren't.

Who exactly do you think is saying this? Because from what I'm understanding, so far Amazon has been decimating teams at the expense of overworking them even more, and by cutting projects at the expense of cancelling maintenance and feature work.

From the article:

> The cuts beginning this week may impact a variety of divisions within Amazon, including human resources, known as People Experience and Technology, devices and services and operations, among others, the people said.

Isn't that scenario a problem only when the output from solar is insufficient to meet the aggregate demand?

From a naive point of view, it looks like this issue would be easily mitigated if supply from solar was increased enough to allow energy to be stored during peak hours so that it could be introduced back in the grid during sunset. Why is this scenario being ignored in a thread on how California is investing in battery energy storage?

I think your comment shows some confusion that it's either the result or cause of some negative experiences.

Starting with GitHub. The primary reason it "just works" is because GitHub, like any SaaS offering, is taking care of basic things like managing servers, authorization, access control, etc.

Obviously, if you have to setup your own ssh server, things won't be as streamlined as clicking a button.

But that's obviously not the point of this post.

The point is that the work you need to do to setup a Git server is way less than you might expect because you already have most of the things already set, and the ones that aren't are actually low-hanging fruit.

This should not come as a surprise. Git was designed as a distributed version control system. Being able to easily setup a stand-alone repository was a design goal. This blog post covers providing access through ssh, but you can also create repositories in any mount point of your file system, including in USB pens.

And, yes, "it just works".

> The official Git documentation for example has its own documentation that I failed to get work. (it is vastly different from what OP is suggesting)

I'm sorry, the inability to go through the how-to guide that you cited has nothing to do with Git. The guide only does three things: create a user account, setup ssh access to that account, and create a Git repository. If you fail to create a user account and setup ssh, your problems are not related to Git. If you created a user account and successfully setup ssh access, all that is missing is checking out the repo/adding a remote repo. If you struggle with this step, your issues are not related to Git.

I'm not OP, but whenever your product is implemented by more than one team you will also have the need to coordinate and set strategic goals as well as accompany and steer each team towards where it's infrastructure/tech stack/systems architecture need to be.

If you do not offer guidance and determine technical directions, each engineer working in each team will happily fill the void and do their best to scratch their itch at the expense of the whole company becoming an unmaintainable big ball of mud.

Let's put things differently: what do you expect will be the output of a company if no one is responsible for things like directing the company's R&D effort, coordinate and specify the company's tech roadmap, even oversee product development.