
Software Engineering at Google - thedance
https://books.google.com/books?id=WXTTDwAAQBAJ
======
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.

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

~~~
thedance
The readability process at Google is a way to gain the ability to submit code
without a language style reviewer. To submit code into google3 (their main
repo for server-side stuff), a changelist requires acceptance by a person or
people who collectively own all of the code being changed, and a person or
people who collectively "have readability" in all of the languages in the
change. The simplest example is there is some C++ code that you own and you
have C++ readability. In this case you need the review of anyone. If you don't
have C++ readability, you need a reviewer who does have it, and they need to
carefully review your change for style.

It used to be that you had to do a "readability review" which was a large
change that you developed specifically to gain readability in some language. A
style reviewer would approve it after (usually) many rounds of comments, and
then thereafter you had C++ readability forever.

More recently some language teams have adopted incremental readability. In
this process you add a language reviewer to all of your changes, and after you
demonstrate that you know what you are doing, they will grant you readability.
I think the Go team was the first group to adopt incremental readability, but
it spread to other languages.

This process is off-putting to people who want to join Google but not be
acculturated to their language style rules. There's a surprising number of
these people. In mainline Google these people simply will not get bonuses,
raises, and promotions. In defective organizations like Android they just
discard Google code quality standards and it shows.

~~~
shaftway
The way I've described it to people is that you need to get at least one
review from someone who...

\- is an Owner of the code

\- has Readability in the language of the code

\- is not you

If you are an owner and have readability, you just need someone who isn't you
to sign off on it. If you don't have ownership or readability you need to get
someone who has those things to sign off. If you can find someone who has
both, great. Otherwise you'll need two people.

Having readability in a language can make you pretty desirable, particularly
if it's in a language that your team doesn't often use. It's hard to get, and
it takes time. My team is pure Java, but once in a long while we check in
Python scripts. Most people have Java readability, but I'm one of two people
on the team with Python, which makes me more valuable to the team.

It's really hard to get someone who isn't on your team to give you a
readability review.

~~~
thedance
Definitely. Being an SRE with C++ readability, for example, is like a
permanent employment guarantee.

I'd like to acknowledge the brilliance of people who name their code files
"foo.javascript" to avoid having to get JS readability.

~~~
shaftway
I'd lump them into the category of people who would make production code
depend on things in experimental to get around code reviews.

~~~
thedance
I’m pretty sure that will trigger reviewed-and-submitted code audits for any
role that handles PII. Don’t want the HN-reading public to get the wrong
impression.

------
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/](http://streamingsystems.net/)

~~~
babbleshack
Did you find a copy with well formatted diagrams?

~~~
AzzieElbab
I have printed version. The diagrams are ok, but seem to be on wrong pages,
too much flipping back and forth

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

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

~~~
nostromo
Just so people know, you can use "favorite" for that.

You can also favorite comments.

~~~
dvfjsdhgfv
I use both. Upvoting for "some day" and favorite for "really useful, check it
this weekend."

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

~~~
markus_zhang
Ah thanks a bunch. Back to my grammar book.

~~~
RMPR
Don't forget to take the GoF while you're at 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](https://arxiv.org/abs/1702.01715)

------
cbhl
I guess it makes sense that a book would be the logical conclusion of Hyrum's
Law ([https://www.hyrumslaw.com/](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.

~~~
kortilla
The “readability” label comes from other “brilliant” Google engineers.

Also, tested code is not the same thing as “testable” code. Mock and monkey
patching can very easily give you 100% coverage of untestable code with
garbage tests.

~~~
joshuamorton
> The “readability” label comes from other “brilliant” Google engineers.

This doesn't mean it leads to complex code.

The Google cpp style guide[0], for example, tries at length to keep code
simple and stresses that even in C++, you should prefer simple things unless
the performance benefits (of, say, nontrivial ownership) are provably
necessary:

> The performance costs of value semantics are often overestimated, so the
> performance benefits of ownership transfer might not justify the readability
> and complexity costs.

[0]:
[https://google.github.io/styleguide/cppguide.html](https://google.github.io/styleguide/cppguide.html)

~~~
kortilla
> > The “readability” label comes from other “brilliant” Google engineers.

> This doesn't mean it leads to complex code.

It does mean that it’s a completely subjective thing coming from other people
in the very same culture of which I’m being critical. It’s like someone
claiming the Chinese government isn’t authoritarian because Chinese citizens
have slapped on the “non-authoritarian” label.

------
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...](https://learning.oreilly.com/library/view/software-engineering-
at/9781492082781/)

~~~
ablekh
Thank you for the link, though I strongly prefer to know full content
structure information, i.e, all relevant sections' page numbers. This allows
me to assess how much relative attention is given to a particular topic. I
believe that a full table of contents should be a mandatory element in visual
book previews for all book publishers and sellers (for outlets lacking visual
previews, this information could be provided in text format).

