Software Engineering at Google: Lessons Learned from Programming Over Time
Original price was: $65.99.$32.99Current price is: $32.99.
Price: $65.99 - $32.99
(as of Oct 22, 2024 14:55:58 UTC – Details)
Today, software engineers need to know not only how to program effectively but also how to develop proper engineering practices to make their codebase sustainable and healthy. This book emphasizes this difference between programming and software engineering.
How can software engineers manage a living codebase that evolves and responds to changing requirements and demands over the length of its life? Based on their experience at Google, software engineers Titus Winters and Hyrum Wright, along with technical writer Tom Manshreck, present a candid and insightful look at how some of the world’s leading practitioners construct and maintain software. This book covers Google’s unique engineering culture, processes, and tools and how these aspects contribute to the effectiveness of an engineering organization.
You’ll explore three fundamental principles that software organizations should keep in mind when designing, architecting, writing, and maintaining code:
How time affects the sustainability of software and how to make your code resilient over timeHow scale affects the viability of software practices within an engineering organizationWhat trade-offs a typical engineer needs to make when evaluating design and development decisions.
From the brand
Explore Software Development
Sharing the knowledge of experts
O’Reilly’s mission is to change the world by sharing the knowledge of innovators. For over 40 years, we’ve inspired companies and individuals to do new things (and do them better) by providing the skills and understanding that are necessary for success.
Our customers are hungry to build the innovations that propel the world forward. And we help them do just that.
Publisher : O’Reilly Media; 1st edition (April 7, 2020)
Language : English
Paperback : 599 pages
ISBN-10 : 1492082791
ISBN-13 : 978-1492082798
Item Weight : 2.1 pounds
Dimensions : 7 x 1.25 x 9.25 inches
Customers say
Customers find the book very valuable to understand and offers insights and ideas from how Google made a billion lines of code. They describe it as an entertaining read and say the writing quality is excellent. However, some customers feel the length is too long.
AI-generated from the text of customer reviews
8 reviews for Software Engineering at Google: Lessons Learned from Programming Over Time
Add a review
You must be logged in to post a review.
Original price was: $65.99.$32.99Current price is: $32.99.
Gabriel Southern –
Recommended Reading for any Software Engineer
Software Engineering at Google starts with the premise that “software engineering is programming integrated over time,” but it is not a programming book. It leaves the syntax and semantics of programming to other books and focuses on the culture, process, and tools that Google uses to support its software engineering activities.Despite being written by over a dozen different contributors, who work at Google, the book itself is carefully edited to share a consistent message. Perhaps this is a reflection of the software engineering processes used at Google to enforce consistency within Google’s codebase.The first section on culture covers topics ranging from how to work on teams, share information, lead teams, and measure productivity. It provides a useful perspective on how Google’s culture has adapted over the past two decades as the company grew from being a startup with a handful of people to having over a hundred thousand employees. These topics don’t typically show up in a software engineering curriculum, but they are very valuable to understand, particularly for engineers and managers at large companies.The second section covers processes that Google has developed over time to improve productivity of a large number of people working together on a large and long-lived codebase. The topics include style guides, code review, documentation, testing, and deprecation. Two of the main lessons are the value that Google gets from consistency in its code (recognizing that code is typically read more than times than it is written), and the importance of effective automated testing that allows engineers to modify code that they did not write while remaining confident that the code still works correctly. Google has been at the forefront of promoting developer written tests (rather than relying on separate QA or validation teams), and many of the tips and techniques described for writing and maintaining effective tests are quite insightful.The final section describes the tools that Google uses to support its software engineering activities. The categories of tools are ones that are useful for any software engineering organization, but the specific details in this chapter are harder to generalize than other topics in the book. Google maintains a single source repository (the monorepo) where all its code is stored and it has built custom tools for version control, code search, build processes, code review, static analysis, dependency management, continuous integration, and compute as a service. Reading the specific details of how and why Google developed these tools is insightful, but many of the tools are tightly integrated in Google’s environment and the techniques described in the chapter may not be generally applicable to other organizations.One thing I felt was missing from the book was a discussion of how Google manages its processes to work with open sources projects and share code with people outside of Google. The book focused on code that is developed internally at Google rather than projects that are developed in collaboration with an open source community (i.e Linux, LLVM). But open source is becoming an increasingly important part of software engineering and Google engineers use and contribute to many open source projects. It would be interesting to know how they collaborate with outsiders who lack access to Google’s monorepo and associated development tools.Despite being over 500 pages long, Software Engineering at Google is relatively quick reading and most of the chapters are self-contained and could be read in any order. The authors presented information about software engineering that is not typically covered in university courses, and the book is recommended reading for any software engineer.
Nilendu Misra –
Chesterton’s Fence, Beyoncé Rule and 1 billion line Change List – How Google does it at scale
Google has open sourced “how” they do everything. This book is about âhow Google runs codeâ. Systems engineers should pair this book with âSite Reliability Engineeringâ (from Google) on âhow Google runs infraâ. Senior org leaders should minimally read the first part (Culture) pairing with âWork Rulesâ (Laszlo bock on âhow Google leadsâ). Security Engineers should buy the very recent âBuilding Secure and Reliable Systemsâ on âhow Google implements defenseâ. Executives should read âHow Google Worksâ by Eric Schmidt on – âhow Google works â!First, It is admirable how the company wants to spread its hard-earned wisdom. Thank you! Many places do many things exceptionally well – but the earnestness to coach and educate others is an extreme rarity – a version of Survivorship Bias – among the âBig Techsâ. Collectively, these five books, âTop Nâ Google Tech Talks (check YouTube) and – depending on your role – coding best practices (check their site) are collectively a combination of top notch combined technical and business education in itself.Very rarely I give a 5-star rating to a technical book, but SEaG is completely worth the two weeks I immersed myself into learning Culture, Processes and Tools of Google Software Teams. The writers are deeply knowledgable, passionate about their crafts and offer insight after insight into topics ranging from human psychology to the flaws of over-embracing mock testing.Not targeting on algorithm, language, tools or libraries, it focuses on âSoftware Engineeringâ as a system, i.e., stuff that is not taught at any school. The book disambiguates âprogrammingâ from âengineeringâ, and walks through the hardest engineering challenge – how to scale.It also offers a treasure of insights and ideas from how Google made a billion lines of code change at one time, or how its automated tests could successfully process 50,000 change requests a day, or how Google Production System is perhaps one of the best machines humans ever engineered. Even if you are working nowhere near Google scale, the book covers a lot of fundamentals, especially on how to sustainably develop software and make objective trade-offs while doing so. I would very highly recommend SEaG to any engineering leader trying to improve her team’s game. For developers, the four extensive chapters on testing should alone be worth the entry price.Notes from the “Culture” – first of three – part of the book (most of these should be organization agnostic) —————————————————————————————————————————-Software Engineering is âProgramming integrated over timeâ. From a reverse lens, code thus becomes a derivative of Software Engineering.A project is sustainable if for the expected life span of the software, you are capable of reactive to valuable changes for either business or technical reasons.The higher the stakes, the more imperfect the trade-off value metrics.Your job as a leader is to aim for sustainability and managing scaling costs for the org, the product and the development workflow.Hyperbolic Discounting – when we start coding, our implicit life-span assignment to the code is often in hours or days. As the late 90s joke went – WORA – Write Once, Run Away!Hyrumâs Law: With a sufficient number of users of an API, all observable behavior of your system will depend on a random person doing a random thing. Conceptually similar to entropy – your system will inevitably progress to a high degree of disorder, chaos and instability. I.e., all abstractions are leaky.Two spectrums of code – one way is hacky and clever, another is clean and maintainable. The most important decision is to ensure which way the codebase leans. It is programming if âcleverâ is a complement, and software engineering if âcleverâ is an accusation!Google’s SRE book talks about the complexity of managing one of the most complex machines created by humankind – Google Production system. This book focuses on the organization scale and processes to keep that machine running over time.Scaling an org means sublinear scaling with regard to human interactions.The Beyoncé rule: âIf you liked it, you should have put a CI test on itâ. i.e., if an untested change caused an incident, it is not the changeâs fault.An average Software Engineer produces a constant number of lines of code per unit time.Treat whiteboard markers as precious goods. Well functioning teams use them a lot!60-70% developers build locally. But Google built its own distributed build system. Ultimately, even the distributed build gets bloated – Jevonâs Paradox — consumption of a resource increase as a response to greater efficiency in its use.Humans are mostly a collection of intermittent bugs.Nobody likes to be criticized, especially for things that arenât finished.DevOps in one sentence: Get feedback as early as possible, run tests as early as possible, think about security & production environments as early as possible – also known as âleft shiftingâ.Many eyes make all bugs shallow. Make reviews mandatory.Three Pillars of Social Interaction – Humility, Respect, Trust.Relationships always outlast projects.You have two paths to choose from – one, learn, adapt and use the system; two, fight it steadily, as a small undeclared war, for the whole of your life.Good Postmortem output – Summary, Timeline, Proximate Cause, Impact, Containment (Y/N), Resolved (Y/N) and Lessons Learned.Psychological safety is the biggest thing in leading teams – take risks and learn to fail occasionally.Software engineering is multi person development of multi-version programs,Understand Context before Changing things – Chestertonâs Fence is a good mental model.Google tends toward email-based workflows by default.Being an expert and being kind are not mutually exclusive. No brilliant jerks!Testing on the toilet (tips) and Learning on the Loo (productivity) are single-page newsletters inside toilet stalls.1-2% of Google engineers are readability (Code Review tool) reviewers. They have demonstrated capability to consistently write clear, idiomatic and maintainable code for a given language. Code is read far more than it is written. Readability (review tool at Google) is high cost – trade-off of increased short-term review latency and upfront costs for long-term payoffs of higher-quality code.Knowledge is the most important, though intangible, capital for software engineering org.At a systemic level, encourage and reward those who take time to teach and broaden their expertise beyond (a) themselves, (b) team, and (c) organizations.On diversity – Bias is the default; Donât build for everyone. Build with everyone; Donât assume equity; measure equity throughout your systems.A good reason to become tech lead or manager is to scale yourself.First rule of management? âAbove all, resist the urge to manage.â Cure for âmanagement diseaseâ is a liberal application of âservant leadershipâ, assume youâre the butler.Traditional managers worry about how to get things done, whereas great managers worry about what things get done (and trust their team to figure out how to do it).Being manager – âsometimes you get to be the tooth fairy, other times you have to be the dentistâ.Managers, donât try to be everyoneâs friend.Hiring: A hires A, while B hires C players.Engineers develop an excellent sense of skepticism and cynicism but this is often a liability when leading a team. You would do well to be less vocally skeptical while âstill letting your team know youâre aware of the intricacies and obstacles involved in your workâ.As a leader – Track Happiness – best leaders are amateur psychologists; Let your team know when theyâre doing well; Itâs easy to say âyesâ to something thatâs easy to undo; Focus on intrinsic motivation through autonomy, mastery and purpose; Delegation is really difficult to learn as it goes against all our instincts for efficiency and improvement.Three âalwaysâ of leadership – Always be Deciding, Always be Leaving, Always be Scaling.âCode Yellowâ is Googleâs term for âemergency hackathon to fix a critical problemâ.Good Management = 95% observation and listening + 5% making critical adjustments in just the right place.To scale, aim to be in âuncomfortably excitingâ space.All your means of communication – email, chat, meetings – could be a Denial-of-Service attack against your time and attention. You are the âfinallyâ clause in a long list of code blocks!In pure reactive mode, you spend every moment of your life on urgent things, but almost none of it is important. Mapping a path through the forest is incredibly important but rarely ever urgent.Your brain operates in natural 90-minute cycles. Take breaks!Give yourself permission to take a mental health day.Everyone has a goal to be âdata drivenâ, but we often fall to the trap of âanecdataâ.Google uses GSM (Goals/Signals/Metrics) framework to select metrics to measure engineering productivity.QUANTS – 5 components of productivityQuality of code; Attention from engineers; Intellectual Complexity; Tempo (how quickly can engineers accomplish something) and velocity (how fast they can push their release out); SatisfactionQuantitative metrics are useful because they give you power and scale. However, they donât provide any context or narrative. When quantitative and qualitative metrics disagree, it is because the former do not capture the expected result!Let go of the idea of measuring individuals and embrace measuring the aggregate. Before measuring productivity, ask whether the result is actionable. If not, it is not worth measuring.
Ilya –
The URL references should be aggregated at the end of each chapter
Great book, but it would have been nice to see all the URL references aggregated at the end of each chapter. See, when I read the book, I don’t want to interrupt my reading flow just to distract myself and open the referenced URL, I want to do that later, once I finish reading the chapter. But because they are not duplicated at the end of the chapter, I end up just skipping them completely.
Will –
Must read if you want to work at Google
Marcos Ribeiro Pereira Barretto –
Great book. Not all ideas to all enterprises but some for any size. The chapter on Culture is perhaps the best.
Amazon Customer –
This is a really good book with many impressive details on how to work in large teams and large codebases. Good read for every kind of programmer: SW, Engineer, Architect, Analyst, Data Scientist, …
Carles –
It is a sensational book, written in a super didactic way, and not at all focused simply on Google, but on general concepts of the industry. In addition, the examples he gives about Google already make it very clear that they most likely do not apply to your workplace, but it is only one of the parts since most of the book focuses on content that can help you. in different situations and concepts that you should know, as well as ideas and suggestions based on different experiences that the authors have had over the years.
M. Scannell –
This book gives a good balance of presenting both the practice of software engineering and the rationale behind it for many of the techniques used at Google.Be warned that many of those techniques (eg a large single repository) are not straightforward or necessarily the right path for most organisations — this isn’t a how-to guide. But many of the lessons learned over the years can be applicable to many others, such as when a large change is required (such as a major upgrade of a library or language) to focus on a small expert team doing it rather than imposing it on everyone else. Thinking about sustainable development (rather than just maintainable) is also a great concept — what is the life time of this code, and can the code be maintained/extended/morph over time to support what is needed?This is why the book is useful — the rationale can give you the understanding for the why, and the fact that Google is practicing it (on such a massive scale) shows that it can be important and useful. The how you apply it will likely be different, as each organisation has its own history, culture, and skillset.