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

191–200 of 352 posts

Re: Software Engineering at Google (2020)

#191

Post by VirusNewbie »

eddd-ddde wrote: post #161
n0zmer wrote: post #26

Earlier quoted context omitted.

I thought so too, but since then I moved over to Cloud and things are a LOT better.

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 reviews and get a fat bonus.

Re: Software Engineering at Google (2020)

#192

Post by emodendroket »

londons_explore wrote: post #171
saalweachter wrote: post #110

Earlier quoted context omitted.

Android Auto was 2015.

Hasn't really seen widespread acceptance. I bet a sample of 100 cars on the freeway, perhaps only 25% would have carplay or android auto connected in the USA, and outside the USA adoption is far lower.

Are you sure?

https://appleinsider.com/articles/23/05/23/carplay-android-a...

> A report from Straits Research found that 98% of newly produced vehicles were compatible with either CarPlay or Android Auto. Meanwhile, 80% of prospective car buyers strongly preferred having these smartphone-based infotainment systems in their new vehicles.

The same research also shows Asia-Pacific to be the biggest market for these products, though North America is the fastest-growing.

Re: Software Engineering at Google (2020)

#193

Post by roody15 »

lhorie wrote: 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…

The decline of google’s search engine has really been dramatic. It honestly is just a poor product at this point and I find myself having to use yandex, bing and variety of other tools now to find what I am looking for.

My guess is that between SEO companies and Google just trying to maximize ad profits the product is in terminal decline

Re: Software Engineering at Google (2020)

#194

Post by ajross »

joshuamorton wrote: post #182
ajross wrote: post #175

Earlier quoted context omitted.

No? The two statements at hand equate to: "Do not add features to the product without adding validation to CI" and "Do not write validation steps CI just to add features to the product". Those are pretty clearly related concepts. And the reason for the disconnect is that the former centers the requirements of integration and not development, which is exactly backwards. CI isn't "the place where you run tests". The pl…

> No? The two statements at hand equate to: "Do not add features to the product without adding validation to CI" and "Do not write validation steps CI just to add features to the product". Those are pretty clearly related concepts. Only if your CI and developer workflow are different. To a first approximation, at Google, I run `blaze test //foo` to test `foo`, and CI invokes the same command when testing `foo`. There…

Clearly we agree. I'm just saying that this "Beyone Rule", naively applied, leads to cargo cult CI disasters (I've seen this happen both within and outside of Google, FWIW, but more outside than in to be fair). The correct philosophy isn't "all tests must be integrated in CI", it's "CI must be able to integrate all tests".

Re: Software Engineering at Google (2020)

#195

Post by alex_lav »

lhorie wrote: 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…

I’ve been unable to “Mark as read” in GMail for two years now.

Re: Software Engineering at Google (2020)

#196

Post by shadowgovt »

lokar wrote: post #188
shadowgovt wrote: post #52

Earlier quoted context omitted.

You're not wrong. Google gets to sidestep a lot of problems other lower-margin companies have because they've spent their whole history being near market-leader on search and ads. Things like "deadlines" were foreign to the company for a long time; when you're already the pack leader, you release new features when you feel like it, not to play catch-up with competitors. You can see them struggle in spaces where that'…

I think people forget that the standard back then in the industry was very high margin servers with redundant everything (psu, network/nic, disks, etc). Going to (eventually) mostly dependable simple servers with no redundancy was a big leap.

There were a couple places in Google's internal infrastructure where they had picked up traditional "big iron" architectures (mostly by acquisitions), and it was funny to observe the sheer plane between their regular best practices and those systems (when they hadn't yet been replaced).

One high-ticket item relied on a huge Oracle database. Every other aspect of that product was patch-on-the-fly, silent-release new versions, forward-and-backwards compatibility of software... But the whole product had regular scheduled outages on the weekends because the Oracle part could not be patched on the fly, had a rigid schema baked into its relational architecture, and had to be brought offline for updates and migrations.

It was like everyone was zipping around in racecars and then they all had to pause for Grandpa to cross the street.

Re: Software Engineering at Google (2020)

#197

Post by izacus »

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

> Cool. Could someone, maybe an ex-googler, comment on which parts of these work well and which don't?

TBH most of this stuff is transferrable and even "common sense" in most of the companies you've worked for. Similarly how Google's SRE book is actually a very good collection of battle won experience on how ops can keep systems more reliable and running.

The book is written in a way that you can easily throw away advice that you don't think useful.

Re: Software Engineering at Google (2020)

#198

Post by nerdchum »

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.

Re: Software Engineering at Google (2020)

#199

Post by hn_throwaway_99 »

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.

Perhaps, but to me everything you put in your comment above just sounds like bad engineering practices in general and not something particularly related to Google processes.

E.g. things like "do feature work on a branch and then code review/run PR checks before merge", "have unit test coverage (being a hard balance to judge what is sufficient coverage)", "have useful comments" - absolutely none of these things I associate with "Google engineering practices", and many of them definitely predate things that were specifically done at Google.

Things I think of when I think about Google practices are things like ensuring data is infinitely horizontally scalable, monorepos, etc. Those things are all scale-specific.

Re: Software Engineering at Google (2020)

#200

Post by vbezhenar »

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.

Tests, comments and code reviews is not something unique to Google. It's a commonly accepted practice. There might be some dark corners, just like there are people who perform version controlling with ctrl+c, ctrl+v technique, but it's not a norm. I don't think that many people would argue against basic software development rules. However being Google is much more than writing tests and doing code reviews.

Being Google means having a team which writes source control management system for you.

Post reply on HN