> The culture of Google is that you hire "the best" developers (say top 0.1%) and hamstring them with process and cumbersome tools so that you need 10x as many of them as another company would need and pay them 3x market rates, but it is OK because (1) at the scale they work at they can amortize the cost over a large user base and (2) they make monopoly products.
This describes basically every FAANG / MANGA company. Or even past that, any company that hit it big with a cash cow and now needs to come up with something new to satisfy shareholders.
In Meta's case, they have 3B MAU, they absolutely hire from the same tier of developers, and (pre-layoffs/economic downturn) they throw 10x more of them than they need at a problem. They even outcomp Google. The number of employees is more because employee growth was an indicator for company growth and only once that became a liability against the stock price it stopped.
Meta is just a newer company than Google.
> Facebook on the other hand, cares about internal DX, sees it a problem when developers are stuck with cumbersome processes, and greases the skids.
I am married to a Meta engineer and have mentored folks that have gone to work there. This might be the case if you work for a product that drives their cash cow of ads, but if you are doing anything that doesn't fit within that narrow bucket ... let's just say our viewpoints diverge significantly.
> The problem with React is that mediocre developers can use it to build big things that are too big for them to handle. The problem with Kubernetes is that above-average developers can use it to build small things they can't handle. And the scalability of Kube is more than almost all of the industry needs.
The problem with the Chrysler 300 is that bad drivers run over people. What does that say about the engineering culture at Chrysler?
Look, I agree that most cloud stuff is overkill, but I have a hard time indicting Google's entire engineering culture over a project they released into the wild 12 years ago that just happens to not fit your use case and that theoretical "above-average" developers wouldn't be able to tell that.
Measurable responses to the environment lag, Moore's law has been slowing down (e: and demand has been speeding up, a lot).
From just a sustainability point, I really hope that the parent post's quote is true, because otherwise I've personally seen LLMs used over and over to complete the same task that it could have been used for once to generate a script, and I'd really like to be able to still afford to own my own hardware at home.
Disclaimer: raised Catholic, now Atheist, married to devout Catholic.
The Church as defined by the institution is a community. I do not see it as a contradiction that the head of the institution is instructing the leaders to not add more layers of abstraction between them and the community, especially when those messages are on the subject of what it means to be human.
It boggles my Detroit-grown mind that so many people claim this about so many thriving cities.
I live in the PNW and regularly visit most of the major cities there and in NorCal. What exactly is more depressing there than any other city of any economic relevance in the nation?
I worked on the MS Word core team for a little over three years from 2010-2014, and de-facto owned a significant part of implementing ODF / OOXML Strict support.
The binary format was a liability for Microsoft to begin with, because of decades of cruft lining up with actual memory alignment. During my tenure there I ran into code my GM had written as an intern and was still intact -- he had 20+ years of tenure (mostly on Word) when I joined the team.
The translation of the file format to XML involved a significant amount of performance degradation if you weren't careful. Hundreds of millions of people use the app monthly, and MS still tries to maintain backwards compatibility. Given that open APIs were a relatively late development for the app, I really don't think in the current reality of what's expected by boards of directors for the companies they oversee that _anyone_ would take years to:
a) define a spec that maintained that backwards compatibility
b) reach whatever nebulous simplicity metric today's HN article wants
c) not get whoever greenlit the project fired for taking that many engineering hours for a and b
This describes basically every FAANG / MANGA company. Or even past that, any company that hit it big with a cash cow and now needs to come up with something new to satisfy shareholders.
In Meta's case, they have 3B MAU, they absolutely hire from the same tier of developers, and (pre-layoffs/economic downturn) they throw 10x more of them than they need at a problem. They even outcomp Google. The number of employees is more because employee growth was an indicator for company growth and only once that became a liability against the stock price it stopped.
Meta is just a newer company than Google.
> Facebook on the other hand, cares about internal DX, sees it a problem when developers are stuck with cumbersome processes, and greases the skids.
I am married to a Meta engineer and have mentored folks that have gone to work there. This might be the case if you work for a product that drives their cash cow of ads, but if you are doing anything that doesn't fit within that narrow bucket ... let's just say our viewpoints diverge significantly.
> The problem with React is that mediocre developers can use it to build big things that are too big for them to handle. The problem with Kubernetes is that above-average developers can use it to build small things they can't handle. And the scalability of Kube is more than almost all of the industry needs.
The problem with the Chrysler 300 is that bad drivers run over people. What does that say about the engineering culture at Chrysler?
Look, I agree that most cloud stuff is overkill, but I have a hard time indicting Google's entire engineering culture over a project they released into the wild 12 years ago that just happens to not fit your use case and that theoretical "above-average" developers wouldn't be able to tell that.