Software Engineering at Google

[ridiculous_fish]

Xoogler here, circa 2015. My reaction is that this is a very google3 (i.e. web services) centered book. But Google contains multitudes and it feels wrong to ignore them.

For example the book has a section called "How Code Review Works At Google." And it goes on to describe strictly the google3 process. But Chrome, ChromeOS, GoogleX, others have different processes. If Google has a proven model, why do so many of its projects deviate from it?

During my time there, the Android team was recruiting internally, advertising "come work on Android, we don't require Readability." It was seen as an internal competitive advantage to reject these processes! What does that say about how they are perceived internally?

I speculate that Android and Chrome and others have distinct processes for a good reason, and that the book is unknowingly slanted towards web-service style engineering.

[packetslave]

It was seen as an internal competitive advantage to reject these processes! What does that say about how they are perceived internally?

It certainly says something about how the Android org was perceived internally during most of the time I was there (2011-2018).

[Shish2k]

> we don't require Readability.

I assume from capitalisation and context that Readability is some very specific and very strict set of rules? I’m curious what would be there that would be so offputting...

[AzzieElbab]

This is probably a very dangerous book that a bunch of monkeys will make into a dogma. On the other hand, this one from Google is awesome http://streamingsystems.net/

[babbleshack]

Did you find a copy with well formatted diagrams?

[KerryJones]

I see a lot of upvotes -- has anyone read this? Is it actually good?

[packetslave]

Upvoted based on the authors (and will definitely be reading)...

Titus is both on the C++ standards committee and did a ton of work working on C++ style and core libraries when I was there.

Hyrum was the king of large-scale refactoring and had (IIRC) more than billion lines of code changed and millions of CLs submitted across all of google by the time I left.

[frank_nitti]

I've listened to a few interviews with Titus Winters on CppCast and gained a tremendous amount of insight on C++ systems development and software engineering in general (as well as Google's approach, obviously). IIRC he is a fundamental part of the Abseil project and hence has a deep involvement in Google's interaction with the broader open source and C++ communities.

If those quick talks were any indication, there will be a lot of value in this book for experienced developers.

[akavel]

I think in such cases it's because people probably use upvotes as bookmarks to "read later" (...some day, for sure!)

[m_a_g]

Upvotes are not for the book, but the newsworthiness of the book.

[gowld]

The book was published today.

[blub]

I didn't upvote but I read the first couple of chapters as a draft. They were pretty good, so I think I'll read the rest of the book.

[wwarner]

I started by clicking one of the icons and read three pages, and I liked each one more than the last.

[jansan]

I read Google, I upvote.

[kgraves]

Not read it, but because it's Google I upvoted it.

[est31]

Note that this is a book, it's not, as you'd initially assume, the paper of the same title. https://arxiv.org/abs/1702.01715

[markus_zhang]

Question for anyone who read the book: Does it make sense for an amateur C++/Python programmer to read it? Thanks.

[anonuser123456]

This book is about writing software at scale. E.g. in an org with thousands of people, who might be using your APIs or systems across multiple revisions for years to decades.

I feel like it's more geared for people that have worked in software for at least a decade and need to break bottlenecks in their org. Either as guidance, or as a sales pitch to show executive management "See Google does it."

[cbhl]

I guess it makes sense that a book would be the logical conclusion of Hyrum's Law (https://www.hyrumslaw.com/).

[bognition]

Can you elaborate, i'm not making the connection

[kortilla]

If you’re interested in becoming a software engineer or are junior, do not read this and cargo cult it because many of these things will not be good practices for 99.99% of the industry.

Google has custom tooling, custom kernels, custom hardware, etc and legions of support at every layer of the stack. Complexity is not eschewed but it is rather embraced if it means some slight improvement in utilization or better looking latency distribution.

Those goals are not sustainable in normal businesses, even tech ones.

Google places very little emphasis on things like code readability and testability because it’s easy for them to do rewrites or just run tests on 1 million cores to shake out race conditions and locks.

Read this for entertainment but don’t try to blindly apply it to your work environment. Most of it will make you a bad engineer for non-FAANG envs.

[thelean12]

> Google places very little emphasis on things like code readability and testability.

Why do you say this? I've seen the opposite.

I can't submit untested code or code that doesn't have "readability" approval. It's certainly not perfect but testability is a huge part of any project I've worked on.

[alarge]

Chiming in here to agree with the others. In particular, finding simple, understandable solutions to complex problems is highly valued at Google. Complex solutions are an anti-pattern.

And the comment about readability and testability is so far different from my experience that I have to wonder where the poster is getting their information. Google code reviews have to be among the most nit-picky I've ever seen in a 30+ year career, with serious attention to detail all the way down to punctuation in comments.

[kinkrtyavimoodh]

> Google places very little emphasis on things like code readability and testability because it’s easy for them to do rewrites or just run tests on 1 million cores to shake out race conditions and locks.

This is complete nonsense. Google's code review and testing and reliability practices are better and more sensible than most big and small companies I have worked for and heard about.

[kwhat4]

I think you have a point here, but it was not well articulated in your post. Much of the industry doesn't focus on software engineering only programming which leads to massive unmaintainable garbage codebases. These are the same people that want to save a few dollars by outsourcing the work to low cost places like India and are too ignorant to realize that the development takes 10x as long for a product that is unusable. My best advice would be to avoid these organizations as they will never value the engineering and only seem to focus on the lines of code output as a metric of productivity. Unfortunately this is a lot of the "industry," however I believe the 99.9% is a bit of an exaggeration. As software engineers, we should find value this sort of information regardless of our current employers opinion and hope that we can land at an institution that values engineering.

[getmeoutofhere]

Are you saying this as an ex-Googler / current Googler? Otherwise, please give some citations for some of your claims.

[teen]

as someone who worked previously at google, and went back to the start up world working with php mysql, this is not true at all

[tituswinters]

The opening chapter is very clear on that point: this is a scouting report of a software ecosystem that works at scale, what things we think are a good idea generally. It is not a "This is how you should do it," in that Google's requirements are a few orders of magnitude different than others (expected code lifetime, codebase size, engineering population, compute requirements).

[ablekh]

Not providing table of contents is IMO offending to potential readers. And, unfortunately, this issue applies not only to this book.

[tituswinters]

https://learning.oreilly.com/library/view/software-engineeri...