18 ms·
Software Engineering at Google
- KerryJones 7y agoI see a lot of upvotes -- has anyone read this? Is it actually good?
- gowld 7y agoThe book was published today.
- akavel 7y agoI think in such cases it's because people probably use upvotes as bookmarks to "read later" (...some day, for sure!)
- nostromo 7y agoJust so people know, you can use "favorite" for that. You can also favorite comments.
- dvfjsdhgfv 7y agoI use both. Upvoting for "some day" and favorite for "really useful, check it this weekend."
- jiveturkey 7y agofavorites show up on your public profile
- akavel 7y agoAFAIK, favorites count as upvotes as well.
- m_a_g 7y agoUpvotes are not for the book, but the newsworthiness of the book.
- frank_nitti 7y agoI'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.
- kgraves 7y agoNot read it, but because it's Google I upvoted it.
- jansan 7y agoI read Google, I upvote.
- bvandewalle 7y agocargocult?
- packetslave 7y agoUpvoted 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.
- wwarner 7y agoI started by clicking one of the icons and read three pages, and I liked each one more than the last.
- blub 7y agoI 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.
- est31 7y agoNote 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
- kortilla 7y agoIf 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.
- getmeoutofhere 7y agoAre you saying this as an ex-Googler / current Googler? Otherwise, please give some citations for some of your claims.
- syndacks 7y agoTheir 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.
- teen 7y agoas someone who worked previously at google, and went back to the start up world working with php mysql, this is not true at all
- Lammy 7y agoHow is it not? Seems like simple economics to me. Something like maintaining a custom kernel distribution takes ${x} amount of engineer time for ${y} amount of “savings” (better perf, custom patches, nonstandard features, whatever). Why bother until you have a fleet of machines large enough for y to be greater than x?
- markus_zhang 7y agoQuestion for anyone who read the book: Does it make sense for an amateur C++/Python programmer to read it? Thanks.
- anonuser123456 7y agoThis 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 7y agoAh thanks a bunch. Back to my grammar book.
- RMPR 7y agoDon't forget to take the GoF while you're at it.
- cbhl 7y agoI guess it makes sense that a book would be the logical conclusion of Hyrum's Law (https://www.hyrumslaw.com/ https://www.hyrumslaw.com/).
- deleted 7y ago[deleted]
- bognition 7y agoCan you elaborate, i'm not making the connection
- AzzieElbab 7y agoThis 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 7y agoDid you find a copy with well formatted diagrams?
- AzzieElbab 7y agoI have printed version. The diagrams are ok, but seem to be on wrong pages, too much flipping back and forth
- ablekh 7y agoNot providing table of contents is IMO offending to potential readers. And, unfortunately, this issue applies not only to this book.
- tituswinters 7y agohttps://learning.oreilly.com/library/view/software-engineering-at/9781492082781/ https://learning.oreilly.com/library/view/software-engineeri...
- ablekh 7y agoThank 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).
- ridiculous_fish 7y agoXoogler 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 7y agoIt 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).
- locopati 7y ago> 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
- Shish2k 7y ago> 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 7y agoThe 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.