Software Engineering at Google: the book that teaches FDEs to think in years, not lines of code
Three Google engineers wrote a book that says very little about writing code. It is about what happens to code after you leave the project, and a forward deployed engineer has to answer that question at every customer.
In brief
- Written by Winters, Manshreck and Wright, published by O'Reilly in 2020, with a free HTML edition on abseil.io.
- Its focus is engineering practice at Google rather than programming or software design, organised into culture, processes and tools.
- Three ideas worth keeping for FDEs: code has to survive over time, every observable behaviour has someone depending on it, and upgrading is a trade-off.
The book separates the two along three axes, time, scale and trade-offs, and FDEs run into all three at every customer.
Graphic: FDE Times
The first chapter of a book with Google in its title does not open with algorithms or architecture. It opens with a short definition: software engineering is programming integrated over time.
That sentence is the key to Software Engineering at Google, the book by Titus Winters, Tom Manshreck and Hyrum Wright. According to Google Research’s page, it was published by O’Reilly in 2020. The authors’ page on Abseil gives the release date as March 2020.
For anyone who wants to work as an FDE, it is a better read than most “clean code” books. Consider the job: if the code you write at a customer keeps running after you have moved on to another project, the book’s question about time is your question too.
Not a coding book, and not a design book either
The Abseil page says plainly that the book is not really about programming but about the engineering practices used at Google. The preface goes further: the book is not about software design. Its content is organised into three groups: culture, processes and tools.
The authors are also careful to say that the experience they describe is not meant to dictate what your organisation should do. That matters for readers anywhere outside Google. You will not have a Google-scale monorepo or a dedicated tooling team, so read it for the way it frames questions, not to copy its processes.
A practical bonus: the authors offer a free HTML edition at abseil.io/resources/swe-book. They still encourage buying the print edition from O’Reilly if you want to support the work.
Idea one: your code has to outlive the project
The book identifies three core differences between programming and software engineering: time, scale and trade-offs. A script written to run once is programming. A data pipeline that runs at a customer for three years, through several generations of engineers, is software engineering.
From there the book defines a sustainable codebase as one in which you are able to change everything that ought to change. The definition says nothing about beautiful code. It is about the ability to change things: swapping a library, patching a security vulnerability, moving to a new runtime version without the system collapsing.
Imagine you deploy an agent for a bank. Six months later the foundation model ships a new version and the SDK changes its interface. If the customer cannot upgrade on their own once you have gone, the deployment is not sustainable, however good the demo looked on handover day.
Idea two: every behaviour will have someone relying on it
Chapter 1 states Hyrum’s Law, named after co-author Hyrum Wright. In essence: with enough users of a system, every observable behaviour of it will be depended on by somebody.
For an FDE, this law explains almost every “but I didn’t change anything” incident. Picture an API you built for a customer that returns results in an order the documentation never promised. Their reporting team quietly relies on that order. You optimise the query, the order changes, and the executive dashboard shows the wrong numbers.
The lesson is the instinct to ask before you change anything: who reads this output, how do they read it, and what might they be relying on that you never promised?
Idea three: upgrading is a trade-off, not a principle
The book does not tell you always to upgrade. The decision depends on the cost of upgrading, the value it brings and the expected lifespan of the project. A prototype that lives for three weeks does not need the same discipline as a core system that lives for ten years.
A tip for interviews: if you are asked about a difficult technical decision, tell the story through these three variables. An answer that spells out cost, value and project lifespan is more convincing than “I chose the newest technology”.
Who should read it, and where to start?
If you have two to four years of experience and have only built features within a single product, start with the Preface and Chapter 1. Those two sections are enough to change how you see your work. After that, read on through the three groups, culture, processes and tools, starting with whichever is closest to the problem you are facing.
If you have five to eight years and have kept systems running through several upgrades, the book will give you the vocabulary to name what you have been through. That vocabulary is valuable in interviews and when persuading a customer why they should not upgrade just yet.
And if you are looking for a book on system design, this is not it; the authors say so themselves.
A good FDE is judged by a question few people ask at demo time: a year after you leave, can the customer’s system still be changed?