Live data from Hacker News

Software Engineering at Google (2020)

abseil.io

241–250 of 352 posts

Re: Software Engineering at Google (2020)

#241

Earlier quoted context omitted.

I always here about Cloud having the worst culture tho? Has that not been the case to you?

People work hard in cloud but there are no MBAs in sight. It’s all very technical work, often very bottom up driven. A lot of the overall goals of cloud are more ambitious than AWS offerings. Reliability is prized more than it is in other areas of Google as well, because customers are so technical and often notice. Not a place to coast, but I’d say most people do a solid 45 a week for those that want to get good revi…

> A lot of the overall goals of cloud are more ambitious than AWS offerings.

In what sense?

Re: Software Engineering at Google (2020)

#242
post #185

I'm stumbling into this thread right after experiencing what appears to be a pretty catastrophic failure of Google's main product. As I write this, the search results for "Google stock" (among other queries) returns zero results ("Your search - google stock - did not match any documents"). I'm not really sure what to make out of these discussions about how X or Y Google engineering is, while the production service is…

found this comment thru google's "filter by latest 24 hours" search

currently logged on a google account, indeed the "google stock" search shows "Your search - google stock - did not match any documents"

it happens with other searches, too; not all of them, but some.

no solution found at the moment except logging on another account / not using an account. no extensions installed either.

Re: Software Engineering at Google (2020)

#243
post #83
post #17

Earlier quoted context omitted.

In my ex-Google experience, here are the stages of denial about something that Google does which is good but the industry doesn't yet embrace. Stage 1: "We're not Google, we don't need [[whatever]]"; Stage 2: Foreseeable disaster for which [[whatever]] was intended to address happens; Stage 3: Giant circus of P0/SEV0 action items while everyone assiduously ignores the [[whatever]]; Stage 4: Quiet accretion, over seve…

Off-topic for this thread, but one of the most poignant quips I remember about Google culture was that the performance-review process was really good at rewarding hard, challenging work that didn't produce much value and not very good at recognizing work that produced lots of value but was not astoundingly difficult. I think you were the one who first noted this.

I recently explained Google's perf process to an employee of the US federal government, and was told that the performance review and promotion processes in the government were simpler and less wasteful.

Re: Software Engineering at Google (2020)

#244
post #83

Earlier quoted context omitted.

Off-topic for this thread, but one of the most poignant quips I remember about Google culture was that the performance-review process was really good at rewarding hard, challenging work that didn't produce much value and not very good at recognizing work that produced lots of value but was not astoundingly difficult. I think you were the one who first noted this.

The performance review process has a small impact on salary. The promo process is not based on value or difficulty, but on the size of the organization that one is running. This is also true for higher level ICs, except they do not manage people, but rather manage/lead projects (which then have a certain amount of people involved). Here's a rough breakdown: - L4 -> 1 person - L5 -> 1-3 people - L6 -> ~7 people - L7 -…

Perf feeds into promotions, which are the real way to raise your long-term salary (both inside and outside of Google).

Re: Software Engineering at Google (2020)

#245

Cool. Could someone, maybe an ex-googler, comment on which parts of these work well and which don't? A lot of other companies get into trouble trying to cargo-cult what Google does when they are operating in very different environments wherein those practices aren't optimal. E.g. different levels of scale. Additionally, critics of Google may point out that their engineering culture may not be great on its own terms -…

DISCLAIMER 1: Current Googler here, but opinions are my own. DISCLAIMER 2: I think from a hands-on-keyboard SWE there is a lot of useful stuff. What you mentioned about Google culture of killing products and such I am not gonna talk about. I recommend chapters about testing first and foremost. Among all the codebases I saw (both OS and proprietary) Google tests are the most comprehensive and reliable. However, If you…

> I think there's no nice off-the-shelf offering for running monorepos out there.

I think Git works perfectly well for 99% of monorepos though. It just doesn’t work for the massive ones. I think its a perfect example of something most codebases shouldn’t follow google on.

Re: Software Engineering at Google (2020)

#246

I thought that the more high status the company would indicate better technology stacks and better quality of engineering.... but all the high status seems to do is pull in people who are really good at politics and doing promotion based development which is kind of counter to the science aspect of computer science.

I've consistently gotten the impression that the difference between high performing organizations like Google and less high-performing organizations is that Google doesn't just _say_ they do this stuff, they actually do it, too. (Or, at least, they used to).

> "High performing"

I havent really see Google doing any innovation in about a decade or more? What have they done significant since maps and android over a decade ago?

Apple stomping them in hardware, openai stomping them in AI, AWS stomping them in cloud, Nvidia stomping them on game streaming.

Google has a monopoly on a big ad network at its core and thats not high performing or innovative.

Re: Software Engineering at Google (2020)

#247

Google is not a good example to look at if you are thinking about enterprise software as these need to be supported long term and Google is not very good at that. They have a history of making breaking changes and discontinuing products. Microsoft is a much better example for business software as they are (were?) paranoid about backward compatibility.

You're confusing software engineering with corporate product support. You can have top-notch ongoing lifetimes for trash products. See for example SAP or anything Oracle.

Product support is an integral part of enterprise software engineering. Product management does not know what adding a new feature or deprecating an old feature means. It is the responsibility of engineering to provide the dependency matrix.

For example, engineering usually tells product, if you change feature A, then it will also affect feature B, C and Z. Otherwise you may end up with contract breaches and SLA violations.

Product lifetime and providing incremental features is a big reason why SAP and Oracle have been successful in the enterprise space and people still pay a lot of money to buy them.

Re: Software Engineering at Google (2020)

#248

Earlier quoted context omitted.

The inventions are to keep the talent stream coming ... to work on ads. The inventions are the small tax they pay to pretend to candidates that they could work on inventions when the vast majority of them will be "allocated" to ads.

You're telling me this stupid, bizarre thing: that Google's major innovation was an HR process. That's fucked-in-the-head just enough that you've made me wonder if it's true.

"The best minds of my generation are thinking about how to make people click ads"

https://quoteinvestigator.com/2017/06/12/click/

Re: Software Engineering at Google (2020)

#249

Earlier quoted context omitted.

Possible. I noticed recently that Google search no longer works with NoScript. It used to work. Not sure when this changed, since I don't often enable NoScript.

[Deleting -- I thought I was replying to the same commenter. Never mind, bradley13! Thanks.]

I'm not the original commenter. I was just tossing in a hypothesis based on my experience.

Re: Software Engineering at Google (2020)

#250
post #54

For all of this, Google doesn’t create very good products anymore. This is a guide that came into being _after_ Google was successful. It’s not _why_ Google became successful. Yes, if you have a mountain of money and a horde of underutilized employees, it’s easy to gold plate your engineering and navel-gaze at your biases.

Whenever I watch/read interviews with people who were successful in some way, they usually downplay the ugly hacks and shortcuts they took to get there, and are quick to say that they "should have done it ". It's really hard to get any insights because of this inherently unreliable narration.

Survivorship bias is a hell of drug.
Post reply on HN