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

301–310 of 352 posts

Re: Software Engineering at Google (2020)

#301

Post by marcyb5st »

nonethewiser wrote: post #245
marcyb5st wrote: post #77

Earlier quoted context omitted.

DISCLAIMER 1: Current Googler here, but opinions are my own. DISCLAIMER 2: I think from a hands-on-keyboard SWE there is a lot of useful stuff. What you mentioned about Google culture of killing products and such I am not gonna talk about. I recommend chapters about testing first and foremost. Among all the codebases I saw (both OS and proprietary) Google tests are the most comprehensive and reliable. However, If you…

> I think there's no nice off-the-shelf offering for running monorepos out there. I think Git works perfectly well for 99% of monorepos though. It just doesn’t work for the massive ones. I think its a perfect example of something most codebases shouldn’t follow google on.

Maybe if you only allow for shallow clones/pulls. I am not sold on vanilla git handling monorepo well. If anybody in the company pushes a huge blob you mess up everyone else and so on. Git and some modifications perhaps yes though

Re: Software Engineering at Google (2020)

#302

Post by marcyb5st »

codeapprove wrote: post #276
marcyb5st wrote: post #77

Earlier quoted context omitted.

DISCLAIMER 1: Current Googler here, but opinions are my own. DISCLAIMER 2: I think from a hands-on-keyboard SWE there is a lot of useful stuff. What you mentioned about Google culture of killing products and such I am not gonna talk about. I recommend chapters about testing first and foremost. Among all the codebases I saw (both OS and proprietary) Google tests are the most comprehensive and reliable. However, If you…

Thanks for the CodeApprove shoutout! If anyone here in the comments wants to try it out, just let me know!

No need to thank me. I didn't try it yet, but we chatted months ago I another HN post and so once in a while I check it out. Any plans to include gitlab as first class citizen?

Re: Software Engineering at Google (2020)

#303

Post by codeapprove »

marcyb5st wrote: post #302
codeapprove wrote: post #276

Earlier quoted context omitted.

Thanks for the CodeApprove shoutout! If anyone here in the comments wants to try it out, just let me know!

No need to thank me. I didn't try it yet, but we chatted months ago I another HN post and so once in a while I check it out. Any plans to include gitlab as first class citizen?

No plans for Gitlab at the moment, but maybe one day!

Re: Software Engineering at Google (2020)

#304

Post by marcyb5st »

zahllos wrote: post #287
marcyb5st wrote: post #77

Earlier quoted context omitted.

DISCLAIMER 1: Current Googler here, but opinions are my own. DISCLAIMER 2: I think from a hands-on-keyboard SWE there is a lot of useful stuff. What you mentioned about Google culture of killing products and such I am not gonna talk about. I recommend chapters about testing first and foremost. Among all the codebases I saw (both OS and proprietary) Google tests are the most comprehensive and reliable. However, If you…

I am a big fan of Anki, and for reasons I wanted to build it on a machine I have on an uncommon architecture (it has a graphical desktop). I have all of the components... rust, typescript, qtwebengine, etc) installed and working. I invested some time in trying to convince bazel that the required dependencies existed, to no avail. Rules broke left right and centre and every time I found the solution, other things brok…

As I mentioned, bazel is a bit messy to set up. I think it's still doable and it brings a lot to the table, but it requires an upfront investment in learning Skylark and/or fight with the various rules provided. Blaze (the internal version) is just great unless you want to do shady things that most likely you shouldn't do anyway.

Re: Software Engineering at Google (2020)

#306

Post by FpUser »

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

I could not care less about what Google practices. They operate on enormous scale and have vastly different goals and values.

Re: Software Engineering at Google (2020)

#307

Post by systemBuilder »

Most people will misinterpret what this book really is. Most people will think, "Hmm if I read this book I can start another google." Nothing could further from the truth. This is a book about how to run a gigantic software organization once it gets huge, rich, and sclerotic. This book has no insight into how to start another Google. The only insight is into where will you end up if your startup ends up huge, rich, and sclerotic, like Google.

Re: Software Engineering at Google (2020)

#308

Post by compiler-guy »

nonethewiser wrote: post #232
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…

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

"On the developer's machine" isn't correct.

They are actually saved within a special file-system called "citc" (Clients-in-the-cloud). It saves literally every single revision of the file written during development. If you hit save, it is saved in perpetuity, which has saved me a bunch of times. Every single one. No need for any kind of commit or anything else.

Further, these saved revisions are all fully accessible to every engineer within the company, any time they want.

Re: Software Engineering at Google (2020)

#309

Post by systemBuilder »

roody15 wrote: post #193
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

They really don't give a shit how many search engineers they drive away with 50+-hour weeks and their endless criticism. When it became uncool to have Google Search on your resume in 2018, I left.

Re: Software Engineering at Google (2020)

#310

Post by cornel_io »

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…

Readability doesn't help Google or anyone else, it's a pure "inmates running the asylum" artifact.
Post reply on HN