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

131–140 of 352 posts

Re: Software Engineering at Google (2020)

#131

Post by compiler-guy »

kyrra wrote: post #24
dboreham wrote: post #6

This part is good: https://abseil.io/resources/swe-book/html/ch13.html#prefer_r...

I'd say it's a tradeoff. If you are entirely driven by tests that include your deps, they will be slow. Unit tests are good at catching basic behavior issues that would show up with an integration test, but it's easier to see the cause. I'm of the opinion that both are needed, but don't put all your eggs in unit tests (they don't need to be perfect). That extra time being spent on integration tests tend to be better…

Google's massive distributed build system also runs tests and so most projects run their dependent tests in parallel on thousands of machines.

Re: Software Engineering at Google (2020)

#133

Post by [deleted] »

syngrog66 wrote: post #125

When I see the font and color contrast scheme on that page I nope aborted fast. and dont tell me I can override it in my browser. Neither my Android phone or Android Chrome honors my expressed wish to override everything with a high contrast, dark theme. A few honor it, many apps and docs do not. That article does not.

[deleted]

Re: Software Engineering at Google (2020)

#134

Post by [deleted] »

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…

[deleted]

Re: Software Engineering at Google (2020)

#135

Post by ajross »

andsoitis wrote: post #103

The Beyoncé Rule More colloquially, this is phrased as “If you liked it, you should have put a CI test on it,” which we call “The Beyoncé Rule."13 From a scaling perspective, the Beyoncé Rule implies that complicated, one-off bespoke tests that aren’t triggered by our common CI system do not count.

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", not because it outlaws them.

Re: Software Engineering at Google (2020)

#136

Post by [deleted] »

andsoitis wrote: post #103

The Beyoncé Rule More colloquially, this is phrased as “If you liked it, you should have put a CI test on it,” which we call “The Beyoncé Rule."13 From a scaling perspective, the Beyoncé Rule implies that complicated, one-off bespoke tests that aren’t triggered by our common CI system do not count.

[deleted]

Re: Software Engineering at Google (2020)

#137

Post by lokar »

water-your-self wrote: post #67
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…

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

In many cases there was no wheel available at the time

Re: Software Engineering at Google (2020)

#139

Post by [deleted] »

[deleted] wrote: post #127
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…

[deleted]

[deleted]

Re: Software Engineering at Google (2020)

#140

Post by UncleMeat »

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 opinion, the monorepo, global presubmit, testing culture and the beyonce rule (if you liked it then you should have put a test on it) are basically a superpower for infrastructure teams. Without these things it'd be utterly impossible for certain kinds of infra refactors to be done and many more would be very very painful.

In the open source world I see a fair amount of "tests are always red, don't worry" and "we can never edit this interface because who knows who it breaks." These problems aren't intractable at Google.

This approach does have its own set of challenges and I do suspect that the monorepo has contributed in some ways to Google's inability or refusal to maintain some older products. But holy cow the ability to do something like move everybody in the company to different vocabulary types is powerful.

Post reply on HN