151–160 of 352 posts
Is the culture section being 100% blank a very wry joke about there being no culture or a mistake? https://abseil.io/resources/swe-book/html/part2.html
The formatting of the table of contents does not convey it well.
A book on software engineering but totally missing how decisions are made around what features to build, what bugs to fix. I would have love to read more on how Google engineers prioritise work, what makes them more creative in terms of building innovative features and products. Also would have love to read how UI engineering is done while working with designers etc.
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 -…
"Readability" works terribly when your company is acquired and your team enters all at the same time. Google has (or had ~10 years ago), a thing called "readability" for each language, where in order to be allowed to commit code to the central "google3" repo, you needed to have written some large amount of code in that language, and needed to have a readability reviewer sign off on your code. The process is designed…
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…
A book on software engineering but totally missing how decisions are made around what features to build, what bugs to fix. I would have love to read more on how Google engineers prioritise work, what makes them more creative in terms of building innovative features and products. Also would have love to read how UI engineering is done while working with designers etc.
Maybe it’s more of a PM culture thing.
But as a dev (not at Google) I’m used to stepping into self-driven mode when PMs are slacking, and it’s a shame for Google that Googlers don’t exhibit this behavior.
A book on software engineering but totally missing how decisions are made around what features to build, what bugs to fix. I would have love to read more on how Google engineers prioritise work, what makes them more creative in terms of building innovative features and products. Also would have love to read how UI engineering is done while working with designers etc.
What you’re describing sounds more like a book on product management?
For all of this, Google doesn’t create very good products anymore. This is a guide that came into being _after_ Google was successful. It’s not _why_ Google became successful. Yes, if you have a mountain of money and a horde of underutilized employees, it’s easy to gold plate your engineering and navel-gaze at your biases.
It depends how you look at it. A lot of products created by Google were good/high quality but were killed anyway. It's sad to see things being killed because they were not "big enough".
Earlier quoted context omitted.
"Readability" works terribly when your company is acquired and your team enters all at the same time. Google has (or had ~10 years ago), a thing called "readability" for each language, where in order to be allowed to commit code to the central "google3" repo, you needed to have written some large amount of code in that language, and needed to have a readability reviewer sign off on your code. The process is designed…
The way it's supposed to work is that acquired teams get lots of support on integration, including readability. This helps your team get integrated into writing Google-style code. Not sure why that didn't work out in this case? (Left Google a year ago)
There's a form to get your corner of the codebase exempted from readability temporarily. This gives your team a quarter or two to build up readability.
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"…
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 -…
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…