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

261–270 of 352 posts

Re: Software Engineering at Google (2020)

#261

Post by 0x000xca0xfe »

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…

Don't know why you are getting downvoted - search quality has declined drastically.

I've had multiple occasions where Google reproducibly fails to find exact matches in the page title (no problem for Bing). This cannot be explained by mysterious AI ranking or Unicode issues since Google gave me zero results, the website is non-political, and the title is just plain ASCII.

This never happened ten years ago. Whatever they are doing now, they are seriously screwing things up.

Re: Software Engineering at Google (2020)

#262

Post by joshuamorton »

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?

It's the equivalent of me being able to view the local, unpushed changes you have in whatever directory you git cloned into.

If that sounds somewhat magical, yes, correct.

Re: Software Engineering at Google (2020)

#263

Post by choppaface »

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.

One conspicuous omission in the ex-google is reflection on killed products like Google Wave, Plus, Glass etc etc etc .. for many of the [whatever] was the gross imbalance between Eng owning the product but ignoring the userbase.

What ex-googlers often fail to grapple with is the product lifecycle (how short it may be) and the value of having diversity in the loop of product testing. Google is designed to be a safe place to focus, and that’s not what the real world is like outside the plex.

Re: Software Engineering at Google (2020)

#264

Post by underdeserver »

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…

Eh, money is only a factor when it comes to scale. That is, Google can afford to hire 30 engineers to support their CI infra, you can't.

Everything else isn't. Unit tests aren't a luxury that Google's infinite riches allow it to have - they pay dividends whenever code exists for more than a few weeks.

You can bet your ass Google engineers don't write unit tests for throwaway code.

CI saves time, and while Google can maintain a team you can afford to pay for Jenkins or GitHub Actions, because not paying for them is more expensive - if your company is to survive for more than 3 months.

Re: Software Engineering at Google (2020)

#265

Post by nostrademons »

hn_throwaway_99 wrote: post #199
jeffbee wrote: post #189

Earlier quoted context omitted.

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

Monorepos actually work better at small scale than at Google scale. I think it's nuts that individual startup founders actually consider microservices; if you are validating out a software product idea, write a computer program, the very simplest one possible, to prove that you can do it and get the general shape of the architecture before you start dividing it into microservices.

I usually see the pressure to split into microservices appear around 20 engineers, just as your single repo is starting to get unwieldy. Knowing that the big companies use a monorepo is pretty important information here, because it may prompt you to invest in tooling to make that one repo less unwieldy rather than splitting into many small repos that will be very difficult if not impossible to merge back together again.

Google doesn't actually plan for infinite horizontal scalability in data. The framing I've found most useful is [Jeff] Dean's Law: "Plan for a 10x increase in scale, but accept that sometime before you reach 100x, you will have to rewrite the system with a different architecture." The reason for this is shifting bottlenecks: as the system gets larger, different aspects become the bottleneck to future scalability, and each time the bottleneck changes you usually need a different architecture. But by planning for an order of magnitude growth, you ensure that you're not artificially introducing bottlenecks, and that you have enough headroom to actually discover the new bottleneck.

Re: Software Engineering at Google (2020)

#266

Post by nostrademons »

choppaface wrote: post #263
jeffbee wrote: post #189

Earlier quoted context omitted.

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.

One conspicuous omission in the ex-google is reflection on killed products like Google Wave, Plus, Glass etc etc etc .. for many of the [whatever] was the gross imbalance between Eng owning the product but ignoring the userbase. What ex-googlers often fail to grapple with is the product lifecycle (how short it may be) and the value of having diversity in the loop of product testing. Google is designed to be a safe pl…

Google's penchant for killing promising products is 100% the result of poor incentives. People are incentivized for launching challenging projects, but they are generally not responsible for the bottom line (which is going to be dwarfed by Search Ads revenue anyway) or for user happiness & brand loyalty (which is challenging to measure). As a result, lots of promising and exciting products are brought to market and then killed, as the easiest way to bring new products to market is to cannibalize the stuff your predecessors did and show how great your alternative is instead.

Re: Software Engineering at Google (2020)

#267

Post by jabradoodle »

underdeserver wrote: post #264
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…

Eh, money is only a factor when it comes to scale. That is, Google can afford to hire 30 engineers to support their CI infra, you can't. Everything else isn't. Unit tests aren't a luxury that Google's infinite riches allow it to have - they pay dividends whenever code exists for more than a few weeks. You can bet your ass Google engineers don't write unit tests for throwaway code. CI saves time, and while Google can…

I don't think only Google are writing unit tests.

Re: Software Engineering at Google (2020)

#268

Post by londons_explore »

emodendroket wrote: post #223
fizigura wrote: post #211

Earlier quoted context omitted.

"connected" vs "compatible with" Tbf. 25% connected is huge. If you just jump into your car to quickly do groceries or pick up your kids, you may not be interested in connecting your phone to your car, even if you really like that feature. So there could be a natural ceiling for the "connected" number and 25% feels getting close to that ceiling actually.

If 80% of buyers express a strong preference for having Carplay/Android Auto I don't think it's reasonable to say that they haven't seen "widespread acceptance."

I read that as "strong preference for having Carplay/Android Auto over the car manufacturers own UI".

And everyone is just frustrated with laggy UI's in cars. But in reality they'll probably still just use Waze with a 10 buck phoneholder suction-cupped onto the windscreen.

Re: Software Engineering at Google (2020)

#269

Post by londons_explore »

VirusNewbie wrote: post #214
londons_explore wrote: post #28

Earlier quoted context omitted.

Google search was 1998. Google Maps was 2005. Gmail was 2004. Android was 2008. Youtube was 2005. Chrome was 2008. Docs was 2006. Translate was 2006. Yet in the last decade, they really haven't had many successes (perhaps with the exception of Google Photos - 2015) One would imagine that with nearly 200,000 employees at least one of them would have a good enough idea for a new product people like. But management and…

K8s, TPU Colab Tensorflow hmmm.

Oh yes - google still has great technology - but they aren't consumer products.

Re: Software Engineering at Google (2020)

#270

Post by Arainach »

MH15 wrote: post #153
drewg123 wrote: post #46

Earlier quoted context omitted.

"Readability" works terribly when your company is acquired and your team enters all at the same time. Google has (or had ~10 years ago), a thing called "readability" for each language, where in order to be allowed to commit code to the central "google3" repo, you needed to have written some large amount of code in that language, and needed to have a readability reviewer sign off on your code. The process is designed…

"Readability" is very much still a thing. It's a mess and would be one of the worst things to take from Google. If you can't enforce the code style you like through autoformatters and linting, it's not worth enforcing.

Autoformatters and linter presubmit checks are used extensively at Google. Readability has nothing to do with those. It exists for everything else - ensuring that code is structured properly and idiomatically. Readability talks about structuring code, using the proper tools and containers where possible, and more. Everything from "that method should be named differently" to "you can use this function to do that thing you just wrote code for" to "this could be done with Immutable containers if you A, B, and C" and so much more.
Post reply on HN