5 ms·

I don't know that they're a fantastic engineering company. I don't know what Google is great at - a few things, which feel like they're successful almost becaus

I don't know that they're a fantastic engineering company. I don't know what Google is great at - a few things, which feel like they're successful almost because they're treated as separate from the rest of the organization. OKRs are one of many parts of that, in my opinion.

mahmoudimus 6y ago
Google engineering is fantastic and respectable. What gives the impression that it is anything else other than excellent?
- staticassertion 6y ago
  My personal opinion is that Google has some really strong engineers, and some pockets of engineering are truly exceptional. That is it. 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.
- deleted 6y ago
  [deleted]
- User23 6y ago
  Well here’s one example: https://reasonablypolymorphic.com/blog/protos-are-wrong/index.html https://reasonablypolymorphic.com/blog/protos-are-wrong/inde.... 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?
  - jdm2212 6y ago
    It is in fact just a joke. New grads write shitty code (I certainly did when I started at Google) and after a few months of attentive reviews they write good clean code. It feels like hazing a bit at first because all us arrogant ivy league types graduate thinking we're geniuses and then it turns out, no, we can't even do the equivalent of fetching coffee correctly and have to be handheld through it. But afterwards people joke about it the way they joke about any other shared experience.
  - summerlight 6y ago
    https://news.ycombinator.com/item?id=21873418 https://news.ycombinator.com/item?id=21873418 The author of that article completely confused about the goal of protobuf. Read this rebuttal comment, written by the previous owner.
    - User23 6y ago
      Thanks for the link. It's quite a weak rebuttal however. For example "this inability to distinguish between unset and default values is a nightmare" is ignored. And, to me, "If it were possible to restrict protobuffer usage to network-boundaries I wouldn’t be nearly as hard on it as a technology" is the most damning criticism and that's also ignored. The so-called rebuttal basically amounts to "we're using it to make oodles of money in the ads pipeline so it must be good software engineering." The claim about success in the market is completely true, but it's also not a rebuttal to the claim that the designers of protobufs are apparently ignorant of current computing theory and just patched together an ad hoc mess. Nobody capable of observation disputes that the standard substandard quality of most professionally written software is no impediment to success in the marketplace, there are too many examples to claim otherwise.
      - jdm2212 6y ago
        > this inability to distinguish between unset and default values is a nightmare 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.
        User23 6y ago
        > wire serialization is a fundamentally different problem from representing data within your application 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 https://en.wikipedia.org/wiki/CDR_coding
- quanticle 6y ago
  Their products, especially their mobile products. 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-planning-tenth-messaging-app-this-ones-another-slack-clone/ https://arstechnica.com/gadgets/2020/01/report-google-planni...

mahmoudimus 6y ago

Google engineering is fantastic and respectable. What gives the impression that it is anything else other than excellent?

staticassertion 6y ago
My personal opinion is that Google has some really strong engineers, and some pockets of engineering are truly exceptional. That is it. 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.
deleted 6y ago
[deleted]
User23 6y ago
Well here’s one example: https://reasonablypolymorphic.com/blog/protos-are-wrong/index.html https://reasonablypolymorphic.com/blog/protos-are-wrong/inde.... 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?
- jdm2212 6y ago
  It is in fact just a joke. New grads write shitty code (I certainly did when I started at Google) and after a few months of attentive reviews they write good clean code. It feels like hazing a bit at first because all us arrogant ivy league types graduate thinking we're geniuses and then it turns out, no, we can't even do the equivalent of fetching coffee correctly and have to be handheld through it. But afterwards people joke about it the way they joke about any other shared experience.
- summerlight 6y ago
  https://news.ycombinator.com/item?id=21873418 https://news.ycombinator.com/item?id=21873418 The author of that article completely confused about the goal of protobuf. Read this rebuttal comment, written by the previous owner.
  - User23 6y ago
    Thanks for the link. It's quite a weak rebuttal however. For example "this inability to distinguish between unset and default values is a nightmare" is ignored. And, to me, "If it were possible to restrict protobuffer usage to network-boundaries I wouldn’t be nearly as hard on it as a technology" is the most damning criticism and that's also ignored. The so-called rebuttal basically amounts to "we're using it to make oodles of money in the ads pipeline so it must be good software engineering." The claim about success in the market is completely true, but it's also not a rebuttal to the claim that the designers of protobufs are apparently ignorant of current computing theory and just patched together an ad hoc mess. Nobody capable of observation disputes that the standard substandard quality of most professionally written software is no impediment to success in the marketplace, there are too many examples to claim otherwise.
    - jdm2212 6y ago
      > this inability to distinguish between unset and default values is a nightmare 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.
      - User23 6y ago
        > wire serialization is a fundamentally different problem from representing data within your application 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 https://en.wikipedia.org/wiki/CDR_coding
quanticle 6y ago
Their products, especially their mobile products. 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-planning-tenth-messaging-app-this-ones-another-slack-clone/ https://arstechnica.com/gadgets/2020/01/report-google-planni...