Google is a fantastic engineering company, but terrible at building products.

Yes, you can find flaws in any of those but it's also hard to find better products in the same category. Google is not in any way "terrible at building products", they are one of the best companies in the whole world in building products.

Maybe it's more accurate to say that Google are one of the best companies in the world at buying products.

All those acquired products were nearly non-existent compared to post-Google era. The founders may deserve some credits, but it's mostly Google's job that bring them into the real products. Let us not be that idea guy; what really matters to success is execution.

EDIT: typo

Add in a company that can fund operations, provide user flow, provide a pool of advertisers, real compensation to engineers, and you have a real success.

I give Google a lot of kudos on this.

Do we really want another SUN Microsystems happenning?

False analogy, because:

- Software provides the most utility, not the hardware, which is why IBM needed Microsoft more than vice versa, and why Android wouldn't have been nearly as much of a success if they'd been absorbed into a single phone hardware company.

- Google in 2005-2010 was a very different company to IBM in 1980; i.e., much more innovative, fast-moving and highly motivated to grow fast to rival the iPhone.

And maybe that would have been for the best. If we look, within a year of the HTC Dream (G1, First commercial Android phone) Nokia released the N900, an amazing device running real Linux.

We could have had Maemo instead of Android.

YouTube is full with ads and fake comments including spam.

I agree with the parent post that Google products benefited most from being first or being acquisitions - it's like Microsoft early 2000s or so.

> gmail is the best

That's a very subjective statement. I don't think gmail is the best webmail out there, but it's certainly one of them. It's also one of the oldest. It also adds the contents of all your emails to their profiling service.

I stand by my statement that Google is terrible at building products, they've only built half of the things you listed and bought the rest. One of them could barely be counted as a success (Cloud), and another isn't a product (Android)

In the last decade, I can't remember a single innovative google original product, or some copy-cat product that is better than the competition

I've been working with GCP a lot during the last two years, and I think the experience is actually quite a bit better than people generally assume or adoption numbers suggest. It's probably not a great fit for large companies with really big engineering departments building really complex systems, but getting started on GCP as a small to medium org is a breeze, products at different levels of abstraction complement each other well (so it's easy to grow) and everything seems to be built to be minimum hassle and require a lot less fiddling by an engineer to get going than the corresponding AWS product. Much better web console than AWS, great K8S offering, BigQuery can do machine learning nowadays, which is actually usable for simple tasks. Everything has lots of sane defaults, it's usually only a couple of clicks to spin up pretty much any resource; in AWS this tends to be a huge pain.

Although, if you're in the EU and bound to a strict interpretation of GDPR, then your experience is going to be absolutely miserable, because there's no way to actually restrict data to stay within the EU for the vast majority of products. A lot of the serverless products has something like "data may be processed in US West or global" hidden in their docs (which legal tells me is a big no-no), and while you can set allowed regions, even BigQuery violates that silently, so that's useless and dangerous as well.

So if they were to get better at selling what they have (which they really, really suck at; we're using them not because, but in spite of, their sales efforts) and maybe discover Europe one day, then it'll be a very strong contender for AWS/Azure.

not anymore

OKRs are one of many parts of that, in my opinion.

Take, for example, Google Tasks. It has, roughly the same number of features, with the same design as when it launched two years ago. Presumably there are engineers assigned to it. What on earth are they doing? Meanwhile, Microsoft Tasks has subsumed all the features of Wunderlist and has become a far better to-do list app. It's a small example, but it's emblematic.

The same applies to Google Apps. Google Docs, Google Sheets, and the rest haven't had any substantial new features or (more importantly) performance improvements in 10 years. Try loading a hundred-page Word document in Google Docs and it still lags out.

And then there's chat. Oh, lord, Google's chat applications. How many do they have again? Five? Six? Which ones are they canceling this year? Every year, they promise that they're going to "unify" [1] chat, and every year they fail to deliver on that promise.

The only product at Google that actually seems to get updated and maintained is search. Everything else is either a half-baked science experiment that is soon to be canceled or a stagnant leftover without a clear product roadmap. You can quibble that this is bad product management rather than bad engineering, but as far I'm concerned, bad product management is bad engineering.

[1]: https://arstechnica.com/gadgets/2020/01/report-google-planni...

The impression is based on lots of anecdotal experience. I know many people at Google, I use many Google products, I talk to other industry leaders about their impressions of Google.

The author of that article completely confused about the goal of protobuf. Read this rebuttal comment, written by the previous owner.

proto v2 and v3 let you distinguish set and unset default values (no idea about v1)

> If it were possible to restrict protobuffer usage to network-boundaries I wouldn’t be nearly as hard on it as a technology

It's a serialization format. It doesn't claim to be anything else. When people use it as their application's heap data model, they're misusing it. People are lazy and love to use their wire format as an internal data model (no one likes writing converters to/from the wire format), so this problem plagues everyone, but wire serialization is a fundamentally different problem from representing data within your application. When you conflate these problems, you get abominations like Java Serialization.

I agree with this and the author of the criticism evidently does too, but his position is that failing to make this distinction indicates that protobufs are poorly designed. I don't see how "programmers are lazy and fail to work around the poor design" is much of a rebuttal.

In my mind a good design has one or more appropriate representations for each abstract type. The marshalled representation is certainly one, but one might also want more than one in memory representation of the same type depending on the problem domain. The old Lisp trick of representing an immutable linked list with a single contiguous block of memory is one example[1].

[1] https://en.wikipedia.org/wiki/CDR_coding

The author never offers any evidence that protobufs fail to make this distinction, just that people are lazy and misuse them.

You can't control what people do with generated types. I don't know how you'd even write a linter for Java or C++ that would know what an appropriate usage of protobufs is, to say nothing of writing such linters for every target language and then integrating them into every possible build system, CI framework, and code review application.

Those thorough Google code reviews you complained about earlier -- one of the things they taught me was not to use protos as the application data model. Read the proto off the wire, then convert it to another type or if you're in a hurry wrap it in another type that does validation checks and hides the proto accessor methods.

I wouldn't try to massage protobufs into satisfying that need, but I do agree that it's an area that should get more research and development. Looking at it from a linter perspective is making the problem way harder than it needs to be though. Verification is, generally speaking, a much more difficult problem than construction. For example it's much easier to construct a product of two large primes than it is to verify that a given number is a product of same. Anyhow, I'm not one of those people who thinks the theorists know everything and practitioners are all idiots, I'm just one of those people who think practitioners should learn from theorists and that, sadly, the former are often irrationally resistant to the notion. Not always though, TLA+ is a great example of a tool working software engineers use to build real systems that are theoretically verifiable.

I was being a bit cheeky about the code reviews. I do think that the reviewers delighted in the opportunity to be shitty to an unseemly degree, but I also agree that it was net beneficial. That said I did find the engineering quality in the SRE orgs was significantly higher than the SWE ones. Which is the complete opposite of every other company I've ever worked for.

Search and AdWords are probably 'well run' by whatever measure. And they make money with radical surplus, kind of like pumping sweet Oil cheaply.

And like such places that have cheap oil, a lot of other things are dysfunctional.

We can look past some failures like 'Wave' as merely taking risk, which is fine. But strategic disasters like 'Google Plus' show an inability to do something coherently across business units.

YouTube, in many ways, has a really, really poor interface and some really bad and slow-moving features. But hey, it makes money.

I worked at a major handset maker that made money hand-over fist on devices, and it was laughable how dysfunctional some things were.

This is normal.

OKRs are probably a minor contribution to G's success, and maybe they help confirm G's unique 'culture' as much as anything, in that it's powerful to be able to say 'this is how we do things here', it's like a kind of 'internal branding'.

I don't know too much about what happened after that, but I suspect not having control over the money making apparatus made it hard to control their destiny, and now we have Verizon owning them and finishing up the death spiral.

I encountered a ton of cool technical solutions to things that were Really Hard Problems in the 90's or 2000's, and that was appropriate for hardware from that era, but the outside world moved on, while everyone inside Yahoo still thought that their shit was hot shit.

There were for sure a lot of smart people still working at the company, but the company had 0 cool factor, so they had an incredibly tough time recruiting and retaining people that could move the state-of-the-art forward.

...and no buzzword management strategy like OKR's or whatever is going to change that fundamental problem.

Google does seem to sabotage a lot of its products, but so far hasn't really sabotaged its core products or its company. As long as they don't destroy the dollar printing press (Adwords/search), they can keep pissing away money on dumb things and it won't kill them.

Shame, because that was the one thing they were quite good at at the time.

I think the existence of other companies that were in similar starting positions, and then subsequently failed, would prove that you need more than just that starting position to succeed.

What allowed them to 'win' in that space decades ago? I don't know, nor do I feel the need to know in order to just much more recent history. It could have been organizational structures that either in a different time, or with a different group of people, or at a different scale, or whatever, were the key. Or something else. I have no comment on it.

But I have a very limited view, having lived in SF for a few years and just having insight into the companies I've seen. I bet there are loads of them that I'm just ignorant to.