> If Google's code writing process really was superior, you'd expect them to consistently produce killer products in other fields.

This is a very simplistic notion of what enables the creation of killer products. That has much more to do with understanding users' needs and identifying market opportunities. Good code writing processes are about code maintenance and scaling engineering effort, not dreaming up the next killer app.

Well, you're of course right about that.

I'll retreat to saying that claims about the superiority of Google's code writing process remain unsubstantiated.

During my 3 years at Google, I observed little brilliance. Not that my little corner of the giant org is a statistically valid sample.

I did see a fair amount of "Google is The Best!" sentiments and rejection of anything invented outside the company.

I was there for well over a decade, and my read on it is that the tools are great for building solutions for all sorts of problems, including web applications and big data analysis systems. The biggest issues with the ability to launch a killer app are IMO:

- The risk aversion to anything that threatens a big existing successful product.

- The product/feature approval processes that implements the above.

- The concern about launching something experimental or half-baked under the brand (vs a startup which does that by default).

Personally, I saw a lot of product and engineering creativity, but it was often stifled or watered down by the above.

Unfortunately good code does not mean a good product, and Google is anything but a good product company.

If anything, these are orthogonal.

I had a front-row seat to some really revolutionary ideas in Google getting to the prototype stage before being squashed in the gears of "We're chasing a market and that's not how users see this product working." Stuff where, if it caught on, it'd be a paradigm shift... But it turns out users don't want every paradigm shift that comes down the lane.

Because Google has (traditionally; this has changed in recent years) a real push-pull in authority between management and engineering leadership, the company can't commit fully to building a quality implementation of a status quo. Nor can it commit fully to chasing entirely new ways of doing things that could shake up an established market. In general, this... Actually kind of works out fine for them, more fine than critics often realize, because neither of those answers are always correct. Sometimes you get Gmail. Sometimes you get Google Drive. And sometimes you get iGoogle or Wave. And sometimes you get the stuff in between, like Reader or App Engine (really popular among the users, but the users don't have the money to make it profitable to commit to it).

I don't think this is true.

It means that you wouldn't expect them to have products that fail because of unresolvable tech problems. You can see plenty of cases like Stadia where the tech was solid but the product strategy and leadership follow through was garbage.

Don't mistake publicly visible products with internal products. There is a lot of amazing infrastructure internally that has no public presence at all.