Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Engineering at Google

books.google.com

Post reply on HN
Print view View original

31–40 of 73 posts

Re: Software Engineering at Google

#31

Post by kortilla »

thelean12 wrote: post #12
kortilla wrote: post #9

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 loo…

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

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.

Re: Software Engineering at Google

#32

Post by kortilla »

kinkrtyavimoodh wrote: post #30
kortilla wrote: post #9

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 loo…

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

I didn’t say anything about reliability now did I?

Re: Software Engineering at Google

#33

Post by kortilla »

alarge wrote: post #18
kortilla wrote: post #9

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 loo…

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 3…

Nit-picky reviews are a smell, not a good thing. It can often mean that the reviewer is not really reviewing the big picture (is the intent of the change being fulfilled, is this the right place in the architecture, etc) and it making up for it by focusing on irrelevant details.

Seriously, code review on punctuation in a comment is not good in any scenario and it speaks nothing to the legibility of the code itself. If anything, it might mean the code is unreadable and the reviewer is too embarrassed to point out that they can’t follow it.

Re: Software Engineering at Google

#35

Post by anonuser123456 »

markus_zhang wrote: post #15

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

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

Re: Software Engineering at Google

#36

Post by kwhat4 »

kortilla wrote: post #9

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 loo…

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.

Re: Software Engineering at Google

#37

Post by 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.

Re: Software Engineering at Google

#38

Post by packetslave »

ridiculous_fish wrote: post #37

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…

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

Re: Software Engineering at Google

#39

Post by joshuamorton »

kortilla wrote: post #33
alarge wrote: post #18

Earlier quoted context omitted.

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 3…

Nit-picky reviews are a smell, not a good thing. It can often mean that the reviewer is not really reviewing the big picture (is the intent of the change being fulfilled, is this the right place in the architecture, etc) and it making up for it by focusing on irrelevant details. Seriously, code review on punctuation in a comment is not good in any scenario and it speaks nothing to the legibility of the code itself. I…

This conclusion doesn't, at all, follow from the premise.

While yes, nit-picky review could mean the reviewer doesn't understand the big picture, an LGTM with no comments at all is more likely to be indicative of missing something.

What you really mean is that nit-picky reviews that don't pick up on actual logic or functionality issues are a smell. Which is true, but isn't usually the case at Google[0]. The chapter on teamwork covers some relevant concepts (like psychological safety).

[0]: https://testing.googleblog.com/2018/05/code-health-understan...

Re: Software Engineering at Google

#40

Post by joshuamorton »

kortilla wrote: post #31
thelean12 wrote: post #12

Earlier quoted context omitted.

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

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.

> 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

Post reply on HN