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

171–180 of 352 posts

Re: Software Engineering at Google (2020)

#171

Post by londons_explore »

saalweachter wrote: post #110
fizigura wrote: post #108

Earlier quoted context omitted.

> There hasn't been any revolutionary new features in android since shortly after launch really. Not visibly. But the tech stack has changed substantially. I'd find it quite an achievement if the UX has largely stayed the same while things under the hood got modernized over and over again and went with the times, subtly bringing innovations to the UX as well without people realizing. It's a feature that things don't…

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.

Re: Software Engineering at Google (2020)

#172

Post by jeffbee »

dinvlad wrote: post #117
jeffbee wrote: post #113

Earlier quoted context omitted.

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…

Yeah, there are no direct translations between git and perforce concepts. The right term within Google would in fact be "pre-submit" not "pre-commit". Before a change is submitted in the Perforce-derived flow it exists only in the author's client and isn't really part of source control in the way that git users are accustomed to pushing their branch to origin.

NB: At that company there are also users of git-compatible and hg-compatible tools, but I am discussing the main perforce-derived flow.

Re: Software Engineering at Google (2020)

#173

Post by MarceColl »

sumtechguy wrote: post #144
MarceColl wrote: post #38

Earlier quoted context omitted.

The tools, design and manpower needed to build a skyscraper are different from those needed to build a 1-story wood house. It's not that the ones that build the wood house are failing to study and adopt the ways of their extremely successful competitors. Now, some of the things you say like unit-testing and user data encryption are ones that I've never seen associated with the "We're not google" mindset, so maybe peo…

"were not google" is usually good for things where people are using cargo cult. I saw at one company that went open floor plan because google did it. No one was happy about that. Retention became very low and everyone bailed out. Emulating google does not fix process and management issues. As what may be at google for a good reason may be an utter failure at another company. There are things all shops can adopt that…

I think you wanted to reply to the same person I replied to? Since I'm saying basically the same thing you do I believe

Re: Software Engineering at Google (2020)

#174

Post by dang »

jsnell wrote: post #7

(2020). Earlier discussions: https://news.ycombinator.com/item?id=31224545 (304 points, 179 comments) https://news.ycombinator.com/item?id=22609807 (222 points, 70 comments)

Thanks! Macroexpanded:

Software Engineering at Google (2020) [pdf] - https://news.ycombinator.com/item?id=31224545 - May 2022 (178 comments)

Software Engineering at Google - https://news.ycombinator.com/item?id=22609807 - March 2020 (69 comments)

Similar sounding but different:

Software Engineering at Google (2017) - https://news.ycombinator.com/item?id=18818412 - Jan 2019 (309 comments)

Software Engineering at Google - https://news.ycombinator.com/item?id=13619378 - Feb 2017 (156 comments)

Re: Software Engineering at Google (2020)

#175

Post by ajross »

joshuamorton wrote: post #159
ajross wrote: post #135

Earlier quoted context omitted.

Pet peeve: There's an anticorrolary though, which is that tests written solely for the requirements of an elaborate CI system tend to hurt and not help. Tests need to be trivially executable and inspectable by developers running on their own systems with minimal support. If they aren't, then all you know is that "It's Broken!" and not how to fix it. Good CI is good because it easily integrates "one-off bespoke tests"…

This is a non-sequitor I think. A bad ci system is independent from the mandate that, functionally "unless we can verify we don't break you, you can't complain when we do".

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 place where you run tests is underneath the software developers' fingers. CI is where you integrate tests developers are already running. And to the extent that is not true, CI stops being a useful tool for development and turns into just another roadblock to evade.

Re: Software Engineering at Google (2020)

#177

Post by dinvlad »

jeffbee wrote: post #172
dinvlad wrote: post #117

Earlier quoted context omitted.

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…

Yeah, there are no direct translations between git and perforce concepts. The right term within Google would in fact be "pre-submit" not "pre-commit". Before a change is submitted in the Perforce-derived flow it exists only in the author's client and isn't really part of source control in the way that git users are accustomed to pushing their branch to origin. NB: At that company there are also users of git-compatibl…

Oh I see, thanks! I was under impression Google has migrated away from Perforce towards an in-house system a while ago, but looks like I was mistaken (or do you mean that system is derived from Perforce?). Edit: I guess its name is Piper..

It’s quite interesting/mind-bending to think of work-in-progress that’s still somehow synced between peers (in fact this is one of those “missing nice-to-haves” I wish Git had, and can only be approximated with wip branches..)

Re: Software Engineering at Google (2020)

#179

Post by carabiner »

Is there a reason to emulate google if your company is not trying to become an adtech behemoth? Google just sells ads, and has not originated a successful product besides search. They have an endless stream of failed pursuits, and so this could be a guidebook on inefficiency and exploratory tangents that don't produce value. That's why they laid off 12,000 employees since this guide was written. If anything, companies should try to follow Apple's workflow, which hasn't had layoffs and has a track record of elegant software that produces value in new areas.

Re: Software Engineering at Google (2020)

#180

Post by dustingetz »

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…

label the tradeoffs?
Post reply on HN