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

111–120 of 352 posts

Re: Software Engineering at Google (2020)

#111

Post by lapcat »

ChrisMarshallNY wrote: post #98
lapcat wrote: post #18

Earlier quoted context omitted.

> I found out that the culture seems to have drastically changed. Can you explain in detail?

I'm not going to go into detail, as I don't think that it's helpful. But I don't think that someone like me would be very welcome there. That is both good and bad. I am certainly not God's Gift to Programming, so they may well be better off without folks like me. They certainly seem to be making a lot of green.

> I'm not going to go into detail, as I don't think that it's helpful.

Wouldn't it be helpful to other people who are interested in working there?

Re: Software Engineering at Google (2020)

#112

Post by dontreact »

londons_explore wrote: post #97
fizigura wrote: post #85

Earlier quoted context omitted.

If you compare the Android from 2008 and the Android from 2023 then you'd soon agree that within these 15 years, the whole thing was re-invented multiple times. And I'm not talking the UX, which has already changed substantially, but I mean the underpinnings.

Sure. But as far as the user is concerned, it is much the same. Touchscreen apps, app store, camera, wifi and phone abilities, app switcher and back button. The user doesn't care that the wheel has been reinvented 3 times along the way... There hasn't been any revolutionary new features in android since shortly after launch really. There have been revolutions in apps. For example, pre 2017 I couldn't just tap a butto…

Uber was founded in 2009, and pretty broadly available by 2014 Grubhub was founded in 2004, I was ordering from there all through college 2007-2011 Google actually put out hangouts in 2013, and Skype could do group calls in 2010

Not trying to downplay what happened after this: it was incremental change that made the products scale and be more usable to more people. I would say the things you describe as revolutions were actually evolutions of earlier products.

Re: Software Engineering at Google (2020)

#113

Post by jeffbee »

dinvlad wrote: post #94
jeffbee wrote: post #61

Earlier quoted context omitted.

I'm not really talking about artisanal 3-man software shops, I'm talking about mid-sized companies with thousands of engineers, who don't realize they are already larger than and facing the same problems as Google was when they started adopting these practices. And to be clear, rejecting something as proven as pre-commit code review is not only to reject the example of Google and many other very successful enterprise…

Curious how pre-commit code review worked, could you please elaborate a bit?

Every change is reviewed by someone other than the author before it lands in the repo. At google they take this a bit further. Every change has to have been either written or reviewed by a designated owner of the code (designated by subdirectory) and one of the participants must be a qualified user of the languages used in the change ("readability"). And they have technical measures in place to ensure that programs running in production descend exclusively from reviewed and committed code.

Pre-commit review is common but not universal in the industry. Some shops practice post-commit review or no review. Some believe review consists entirely of quibbling.

Re: Software Engineering at Google (2020)

#114

Post by jeffbee »

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.

I miss you too, raldi.

Re: Software Engineering at Google (2020)

#115

Post by UncleMeat »

BurningFrog wrote: post #36
FartyMcFarter wrote: post #27

Earlier quoted context omitted.

I don't understand your argument - why is the one trick pony revenue generation incompatible with high quality systems and processes for writing code? Both can be true at the same time, and my feeling is that they are, having worked there. The business is not very diversified, and the tools are great.

If Google's code writing process really was superior, you'd expect them to consistently produce killer products in other fields. But I can't think of anything like that in the last 15 years.

I don't think this is true.

It means that you wouldn't expect them to have products that fail because of unresolvable tech problems. You can see plenty of cases like Stadia where the tech was solid but the product strategy and leadership follow through was garbage.

Re: Software Engineering at Google (2020)

#116

Post by siliconc0w »

IMO bang for buck is to invest in:

* reproducible fast dev environments - anyone should be able to build anything pretty easily fairly quickly

* culture of design reviews, testing, and code reviews.

* CI/CD, static analysis, PaaS, dependency management.

You can do all of these without Google-level or really any bespoke tooling. A lot of what google builds is for operating at Google scale - distributed builds and running of huge applications - and even then this tooling this simply enables working at this scale, it comes with a lot of cost(speed/complexity) and jank you don't need at smaller software shops.

Re: Software Engineering at Google (2020)

#117

Post by dinvlad »

jeffbee wrote: post #113
dinvlad wrote: post #94

Earlier quoted context omitted.

Curious how pre-commit code review worked, could you please elaborate a bit?

Every change is reviewed by someone other than the author before it lands in the repo. At google they take this a bit further. Every change has to have been either written or reviewed by a designated owner of the code (designated by subdirectory) and one of the participants must be a qualified user of the languages used in the change ("readability"). And they have technical measures in place to ensure that programs r…

Oh, I see - by "pre-commit" it doesn't really imply it in "Git commit" sense - the change is still propagated to others (presumably by committing it as a sort of "draft"), it's just not committed to the mainline - is that correct?

I'm very familiar with CR at other companies, but tbh since most use Git, I wouldn't call that "pre-commit" but "pre-merge", if you will - unless I misunderstood and it really is pre-commit at Google (i.e. the changes are not even _committed_ to the repository - and then I'm confused once again at what exactly that means..)

Re: Software Engineering at Google (2020)

#118

Post by compiler-guy »

BurningFrog wrote: post #36
FartyMcFarter wrote: post #27

Earlier quoted context omitted.

I don't understand your argument - why is the one trick pony revenue generation incompatible with high quality systems and processes for writing code? Both can be true at the same time, and my feeling is that they are, having worked there. The business is not very diversified, and the tools are great.

If Google's code writing process really was superior, you'd expect them to consistently produce killer products in other fields. But I can't think of anything like that in the last 15 years.

Don't mistake publicly visible products with internal products. There is a lot of amazing infrastructure internally that has no public presence at all.

Re: Software Engineering at Google (2020)

#119

Post by BurningFrog »

danans wrote: post #43
BurningFrog wrote: post #36

Earlier quoted context omitted.

If Google's code writing process really was superior, you'd expect them to consistently produce killer products in other fields. But I can't think of anything like that in the last 15 years.

> If Google's code writing process really was superior, you'd expect them to consistently produce killer products in other fields. This is a very simplistic notion of what enables the creation of killer products. That has much more to do with understanding users' needs and identifying market opportunities. Good code writing processes are about code maintenance and scaling engineering effort, not dreaming up the next…

Well, you're of course right about that.

I'll retreat to saying that claims about the superiority of Google's code writing process remain unsubstantiated.

During my 3 years at Google, I observed little brilliance. Not that my little corner of the giant org is a statistically valid sample.

I did see a fair amount of "Google is The Best!" sentiments and rejection of anything invented outside the company.

Re: Software Engineering at Google (2020)

#120

Post by ajross »

flohofwoe wrote: post #21

Probably a bit off-topic, but since I'm a bit triggered by the 'abseil' in the domain name: I wish Google would relax their 'guidelines' when it comes to software that's also published outside of Google. Case in point: the Dawn C++ library (Google's native WebGPU implementation) has a dependency on abseil, and from what I've seen when glancing over the code, the only reason seems to be some minor string-related stuff…

> I can only assume that there must be some interal NIH rule inside Google to use abseil in place of the C++ stdlib

FWIW my understanding is that this is exactly backwards: Abseil exists because the internal code and toolchain evolved to use features that hadn't landed in the standard yet, and releasing the support this way allows that dependent code to be used in open source releases. It's not about features Googler's "can't" use, it's that they[1] could always use better stuff, and this is a way to get the better stuff released so non-Googlers could use it at all (and then, apparently, complain about it).

Obviously looking at this in hindsight from the outside of a project using gcc13/clang15, it seems like it's needlessly different. But when written it was forward-looking.

[1] "We", I guess, though I work in ChromeOS and not in this world.

Post reply on HN