Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Engineering at Google (2020)

abseil.io

Post reply on HN
Print view View original

251–260 of 352 posts

Re: Software Engineering at Google (2020)

#251

Post by fcpk »

pclmulqdq wrote: post #244
H8crilA wrote: post #229

Earlier quoted context omitted.

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).

This is a terrible process unfortunatelly. Raising the salary should be related to the usefulness of the person to the company, and not the breadth/impact of their work. This leads to terrible things like gaming the system to get high impact/leadership projects to get raises which comes with huge side effects, like projects getting abandonned fast, being deprecated in favor of new shiny promo-bringing things.

But this is not just a Google specific issue, and it is quite widespread in the industry. Google however suffered from this especially due to its obsessive culture of pay-for-perf and by ignoring simple facts:

- inflation means that your salaries should raise regardless of performance. if you only tail the market by adjusting salaries only if the market changes, then you are 1 year late(at least). This isn't a problem in an economy with low inflation, but is a huge problem in one with much higher inflation.

- there is a significant number of people needed to maintain projects that won't show large impact. Those people need to be at the very least recognized and compensated.

- making new products is great, but it requires huge amounts of ressources to do at Google scale from the get-go. A wider strategy is much needed, which Google obviously lacked for almost a decade.

Re: Software Engineering at Google (2020)

#252

Post by UncleMeat »

nonethewiser wrote: post #238
UncleMeat wrote: post #140

Earlier quoted context omitted.

In my opinion, the monorepo, global presubmit, testing culture and the beyonce rule (if you liked it then you should have put a test on it) are basically a superpower for infrastructure teams. Without these things it'd be utterly impossible for certain kinds of infra refactors to be done and many more would be very very painful. In the open source world I see a fair amount of "tests are always red, don't worry" and "…

I dont think its fair to classify code review and test coverage as “the google way.” Should evaluate more by the unique things google does or the things they specifically invented (not code review and testing). And of course volunteers working on open source projects have lower standards. Lets instead compare Google to companies which say “we arent google.”

What I am describing is not code review and test coverage. What I am describing is the ability to run all of the tests for the entire company in one go so you can safely make absolutely massive changes to the codebase.

Re: Software Engineering at Google (2020)

#253

Post by UncleMeat »

raldi wrote: post #83
jeffbee wrote: 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.

There's a lot of external complaining about perf at Google. My experience is that most of these complaints are wrong. I've personally had two reports fail to get promoted to L6 off of projects that were very difficult and executed well but for various reasons did not have the impact that we expected.

Re: Software Engineering at Google (2020)

#254

Post by UncleMeat »

nonethewiser wrote: post #235
joshuamorton wrote: post #186

Earlier quoted context omitted.

> Edit: as OP mentioned, it does seem to differ in technical sense from traditional CR, in that the changes live only on developer machine, not in source control. Yes and no. There's a decent whitepaper on Piper and citc you can find by searching for it (or actually I will :P [0]), as far as piper is concerned they aren't checked into source control, but the vast majority of development happens in "citc" workspaces,…

> and I can open up a readonly view of someone else's workspace if I know the right incantations So thats not just a basic feature?

The normal workflow is to create a changelist and then have somebody patch that changelist into their client rather than accessing their client directly.

Re: Software Engineering at Google (2020)

#255

Post by philote »

natch wrote: post #157
x86x87 wrote: post #80

Earlier quoted context omitted.

It depends how you look at it. A lot of products created by Google were good/high quality but were killed anyway. It's sad to see things being killed because they were not "big enough".

The ones that were not killed are atrociously shoddy and have been now for, you’d think I was going to say years, but it’s actually decades.

I feel like even their main products are shoddy as well. How can they recommend good, relevant ads if they can't even recommend good news articles, music, or videos? If I do any search in Google on a topic, even if it's just to get a tiny bit of info about that topic, Google decides I'm interested in it and will make recommendations based on that one, single search. Or sometimes I'll buy a product and start seeing ads for similar products later. That's not good targeting IMO.

Re: Software Engineering at Google (2020)

#256

Post by H8crilA »

pclmulqdq wrote: post #244
H8crilA wrote: post #229

Earlier quoted context omitted.

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).

Perf is almost irrelevant for promotions beyond level 5.

Re: Software Engineering at Google (2020)

#257

Post by majesticglue »

jeffbee wrote: post #189
hn_throwaway_99 wrote: post #184

Earlier quoted context omitted.

Strong disagree. In my experience, this is not commonly why competitors don't adopt Google's practices. The main reasons I've seen are: 1. Money. Google essentially has a giant, gargantuan, enormous, bottomless pit of money to build a lot of this tooling (and also to take the risk if something ends up not working out). I think you might be able to say that other companies are just being short sighted if they don't im…

Just discussing your point #1, I hear this but what I see is that the companies I have direct experience with spend much more and move more slowly with their we-are-not-Google hacks. People move fast and break things into a corner where their entire project is a haunted graveyard with no test and no comments, that has never been reviewed, and at that point nobody is allowed to change anything.

clearly there is a missing link in your experience of companies where you don't have control over a lot of the things you think is needed and companies want to push a product as fast as possible and cut as many corners as possible.

More and more companies will be like this to cut costs

Re: Software Engineering at Google (2020)

#258

Post by yibg »

jeffbee wrote: post #17
mushufasa wrote: post #4

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 -…

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…

There is risk of selection bias here. The companies that runs into [[whatever]] are the ones that made it far enough to have run into it. What you're not seeing are all the companies that tried to do what google does at scale, built a complex code base that doesn't serve it's customers needs and can innovate fast enough and are now dead.

Re: Software Engineering at Google (2020)

#259

Post by blitz_skull »

phendrenad2 wrote: post #231
7e wrote: 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.

There was a great (IMO) article posted here on HN the other day about this very topic: https://news.ycombinator.com/item?id=37100226

Re: Software Engineering at Google (2020)

#260

Post by Terr_ »

phendrenad2 wrote: post #231
7e wrote: 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.

Obligatory: https://xkcd.com/1827/

I'm also reminded of something written by Scott Adams (decades ago, when his reputation was different.)

> Most people won't admit how they got their current jobs unless you push them up against a built-in wall unit and punch them in the stomach until they spill their drink and start yelling, "I'LL NEVER INVITE YOU TO ONE OF MY PARTIES AGAIN, YOU DRUNKEN FOOL!"

> I think the reason these annoying people won't tell me how they got their jobs is because they are embarrassed to admit luck was involved. I can't blame them. Typically, the pre-luck part of their careers involved doing something enormously pathetic.

-- "The Dilbert Future" (1997), by Scott Adams

Post reply on HN