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

61–70 of 352 posts

Re: Software Engineering at Google (2020)

#61

Post by jeffbee »

MarceColl wrote: post #38
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…

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…

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 enterprises, but also to ignore decades of developer productivity knowledge before Google existed. It's almost like the fact that Google adopted a long-standing best practice makes modern engineers reflexively revolt against those best practices. This can only be seen as a structural advantage for Google.

Re: Software Engineering at Google (2020)

#62

Post by tylerhou »

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…

For string related stuff — there’s not much in the stdlib that can replace the stuff in abseil. (Haven’t looked at Dawn in particular, though.)

E.g. absl::StrFormat — no equivalent until std::format was standardized in C++20.

absl::StrCat: You could use streams, but, ew. Also, StrCat is optimized to reserve sufficient size in advance, so it is more efficient than appending to a string or using a std::stringstream.

absl::Cord. No equivalent in the stdlib.

Re: Software Engineering at Google (2020)

#63

Post by lordnacho »

ChrisMarshallNY wrote: post #16
ye-olde-sysrq wrote: post #11

"As far as this outsider can tell, the systems and processes for writing code at Google must be among the best in the world, given both the scale of the company and how often people sing their praises." Is this really the case? In high school I sure thought Google was a magical software heaven us mortals could but dream of working for, but now (and increasingly as of late) I'm strongly under the impression that 20 ye…

Apple has undergone a similar ossification. I think it's just something that happens to companies that get a certain size. The Process becomes more important than the Product. When I was younger, I wanted so badly, to work at Apple. A few years ago, they actually approached me, and I found out that the culture seems to have drastically changed. They ended up not wanting me anyway, so maybe it's just sour grapes, on m…

When you have the golden goose, you don't actually know how it makes the gold. You think you know, and you aren't completely clueless, but you don't really know, because it's complicated.

The obvious thing to do then is to not change too many things around it. Or at least document the changes.

So then you get a bunch of processes that are designed to not rock the boat too much, in case the magic dies.

Re: Software Engineering at Google (2020)

#64

Post by matwood »

ChrisMarshallNY wrote: post #16
ye-olde-sysrq wrote: post #11

"As far as this outsider can tell, the systems and processes for writing code at Google must be among the best in the world, given both the scale of the company and how often people sing their praises." Is this really the case? In high school I sure thought Google was a magical software heaven us mortals could but dream of working for, but now (and increasingly as of late) I'm strongly under the impression that 20 ye…

Apple has undergone a similar ossification. I think it's just something that happens to companies that get a certain size. The Process becomes more important than the Product. When I was younger, I wanted so badly, to work at Apple. A few years ago, they actually approached me, and I found out that the culture seems to have drastically changed. They ended up not wanting me anyway, so maybe it's just sour grapes, on m…

> The Process becomes more important than the Product.

I don't know if the process is more important, but at a certain size codified process becomes a requirement.

Re: Software Engineering at Google (2020)

#65

Post by lesuorac »

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…

I just wish more places would adopt `third_party`; I would also love reproducible builds but I'll settle on third_party.

Re: Software Engineering at Google (2020)

#66

Post by fidotron »

outside1234 wrote: post #30
NoMoreNicksLeft wrote: post #12

Earlier quoted context omitted.

> Additionally, critics of Google may point out that their engineering culture may not be great on its own terms -- every time Google launches a new feature, people post links to the Google product graveyard. It is personally scary when they develop new products. What if it is a brilliant idea, one I cannot live without? If Google develops it, then I am looking at this stillborn thing, mewling for life when I know it…

The inventions are to keep the talent stream coming ... to work on ads. The inventions are the small tax they pay to pretend to candidates that they could work on inventions when the vast majority of them will be "allocated" to ads.

It's also Google licking the cookie. They maintain a moat around ads by doing just enough to threaten to destroy anyone that gets close to their ecosystem.

Facebook survived because G+ product vision was so out of touch with reality and FB were not part of the anti-compete hiring nonsense so that they managed to poach a lot of good people.

Re: Software Engineering at Google (2020)

#67

Post by water-your-self »

danpalmer wrote: post #35
ye-olde-sysrq wrote: post #11

"As far as this outsider can tell, the systems and processes for writing code at Google must be among the best in the world, given both the scale of the company and how often people sing their praises." Is this really the case? In high school I sure thought Google was a magical software heaven us mortals could but dream of working for, but now (and increasingly as of late) I'm strongly under the impression that 20 ye…

The tooling is great in some ways, but possibly not in the way you'd expect. There is a tool that will do almost anything, but the tools are often just a bit janky. Rather than thinking of the toolchain as some polished, tightly integrated, perfect system, think of it more like an internal open-source ecosystem of things that work together but which are made by individuals, with limited resources, that still feature…

>most tools are exactly the same sort of thing that you'd create in any other place, we just have more of them

Why? Why reinvent the wheel 10 times?

Re: Software Engineering at Google (2020)

#68

Post by ownagefool »

ye-olde-sysrq wrote: post #11

"As far as this outsider can tell, the systems and processes for writing code at Google must be among the best in the world, given both the scale of the company and how often people sing their praises." Is this really the case? In high school I sure thought Google was a magical software heaven us mortals could but dream of working for, but now (and increasingly as of late) I'm strongly under the impression that 20 ye…

Probably all of the above is true.

From an outsiders, it looks like all of FAANG has scaled to the point where delivery, perf and managing the business has become quite cumbersome. This, I suspect is why they're all used the economic climate to cut back, as they largely are unable to see the benefit of the additional hiring.

I have no doubt most of the talent is top tier, but being a strong engineer doesn't deliver profits nor cost savings on it's own.

Re: Software Engineering at Google (2020)

#69

Post by scarmig »

88913527 wrote: post #45
danpalmer wrote: post #35

Earlier quoted context omitted.

The tooling is great in some ways, but possibly not in the way you'd expect. There is a tool that will do almost anything, but the tools are often just a bit janky. Rather than thinking of the toolchain as some polished, tightly integrated, perfect system, think of it more like an internal open-source ecosystem of things that work together but which are made by individuals, with limited resources, that still feature…

I have yet to be impressed by internal software tools developed by one team and consumed by another. You're likely being friendly and understating the degree of jank which is present.

It's janky, and when you do choose to use a best-effort tool with no dedicated support, you absolutely have to plan for it being a pain point and the likelihood of eventual migration.

That's true at Google, just as it's true anywhere. But what makes Google a much better experience than most places is a willingness (and ability) to pay for internal dev tooling of every sort with dedicated headcount. And that results in a consistently better experience than pretty much anywhere (I understand Meta has a comparable culture and ability to fund it, and I wouldn't be surprised if some or many of their internal tools surpass Google's). It's also unfortunately not replicable as a strategy, because you need a giant money spigot to make it work.

Re: Software Engineering at Google (2020)

#70

Post by xyzzy_plugh »

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 cannot more strongly endorse this.

It would be tremendously beneficial if their software dropped the abseil dependency, especially where it is almost entirely unused. Hell it'd be better if they simply vendored the bits they need.

Having to use Bazel, and having to manage an additional dependency like abseil can be hellish for small projects with uncomplicated build systems.

The worst part is that abseil leaks through interfaces and you end up being coupled to it as a consumer of a library. It's bananas. I don't need yet another stdlib.

Post reply on HN