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.
Another is the frat boy hazing code review culture. Heck there are plenty of noogler’s first code review memegens floating around. It’s totally not bullying it’s just joking right?
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].
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.
OKRs are one of many parts of that, in my opinion.