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

41–50 of 73 posts

Re: Software Engineering at Google

#41

Post by kortilla »

joshuamorton wrote: post #39
kortilla wrote: post #33

Earlier quoted context omitted.

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

The comment I replied to is literally highlighting people nit-picking punctuation as if it’s a good thing.

Re: Software Engineering at Google

#42

Post by kortilla »

joshuamorton wrote: post #40
kortilla wrote: post #31

Earlier quoted context omitted.

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

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

Re: Software Engineering at Google

#43

Post by joshuamorton »

kortilla wrote: post #41
joshuamorton wrote: post #39

Earlier quoted context omitted.

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

The comment I replied to is literally highlighting people nit-picking punctuation as if it’s a good thing.

Which it is!

You seem to be assuming, without prompt, that nit-picking punctuation comes at the expense of a thorough overall review.

Code review on punctuation is absolutely an important part of readability. Consistency makes understanding and scanning (for human readability) and potentially parsing and modifying (for machine readability) much easier.

As someone who both reviews a lot of code and reads a lot of code, consistent documentation with good grammar and punctuation is enormously helpful.

Re: Software Engineering at Google

#44

Post by markus_zhang »

anonuser123456 wrote: post #35
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."

Ah thanks a bunch. Back to my grammar book.

Re: Software Engineering at Google

#45

Post by syndacks »

getmeoutofhere wrote: post #10
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…

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

Their Google status is irrelevant. The nature of their comment is that there's a propensity to emulate big tech when it's not needed. Off the top of my head: Kubernetes, microservices. My citation is news.ycombinator.com.

Re: Software Engineering at Google

#46

Post by RMPR »

markus_zhang wrote: post #44
anonuser123456 wrote: post #35

Earlier quoted context omitted.

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

Ah thanks a bunch. Back to my grammar book.

Don't forget to take the GoF while you're at it.

Re: Software Engineering at Google

#47

Post by locopati »

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 explains a lot about the state of AndroidOS and the instability of updates

Re: Software Engineering at Google

#50

Post by tituswinters »

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…

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).
Post reply on HN