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

231–240 of 352 posts

Re: Software Engineering at Google (2020)

#231

Post by phendrenad2 »

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.

Re: Software Engineering at Google (2020)

#232

Post by nonethewiser »

dinvlad wrote: post #164
joshuamorton wrote: post #154

Earlier quoted context omitted.

Google (for $reasons) doesn't do long lives code branches and doesn't use git, at least for the main repo. So in that context every commit is reviewed pre-commit, but you'd do the same workflow elsewhere with trunk-based development, small pull requests, and CI and automated and human review of all PRs before they're merged.

Right, I know it’s not on Git and hence was my question - and it sounds like this is more about terminology and less about technology. I.e. what Google does in this case is not that different from just “Code Review” in the traditional sense, as most other companies (with good engineering practices) do - reviewing code before it enters production (+CI/CD, as you mentioned). Edit: as OP mentioned, it does seem to diffe…

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

Which seems worse.

Re: Software Engineering at Google (2020)

#233

Post by RichardCA »

hn_throwaway_99 wrote: post #184
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…

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…

I think it's also the ability to have a deep bench of coding talent who just get to work on the toolchain. Most companies ration that talent to the product, shipping features that drive revenue.

Re: Software Engineering at Google (2020)

#234

Post by iaseiadit »

w10-1 wrote: post #230

As a counterpoint to the engineering/product/culture comments providing context on the book, I would point out that Urs Hölzle has recently stepped back from uber-manager to individual contributor in the infrastructure space. This is the guy who built the hotspot JIT that added decades to the life of Java, and who engineered Google's data centers and GCP. He obviously doesn't need more money or glory or experience, s…

Did he have any involvement in this book?

He’s not an author and not in the acknowledgments: https://abseil.io/resources/swe-book/html/pr01.html#_acknowl...

Re: Software Engineering at Google (2020)

#235

Post by nonethewiser »

joshuamorton wrote: post #186
dinvlad wrote: post #164

Earlier quoted context omitted.

Right, I know it’s not on Git and hence was my question - and it sounds like this is more about terminology and less about technology. I.e. what Google does in this case is not that different from just “Code Review” in the traditional sense, as most other companies (with good engineering practices) do - reviewing code before it enters production (+CI/CD, as you mentioned). Edit: as OP mentioned, it does seem to diffe…

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

Re: Software Engineering at Google (2020)

#236

Post by SNosTrAnDbLe »

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.

Re: Software Engineering at Google (2020)

#238

Post by nonethewiser »

UncleMeat wrote: post #140
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 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.”

Re: Software Engineering at Google (2020)

#239

Post by pclmulqdq »

w10-1 wrote: post #230

As a counterpoint to the engineering/product/culture comments providing context on the book, I would point out that Urs Hölzle has recently stepped back from uber-manager to individual contributor in the infrastructure space. This is the guy who built the hotspot JIT that added decades to the life of Java, and who engineered Google's data centers and GCP. He obviously doesn't need more money or glory or experience, s…

Are we thinking about the same Urs? His reputation was not particularly good when I was in the TI group at Google recently. He also had nothing to do with this book.

Re: Software Engineering at Google (2020)

#240

Post by cratermoon »

SNosTrAnDbLe wrote: post #236

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.
Post reply on HN