45 original guides across 5 shelves — the full index of everything on Compiled. A complementary collection of engineering lessons is available in Software Engineering at Google.
Robert C. Martin's book gave a generation of developers a shared vocabulary for code quality — and a shared argument about where that vocabulary runs out. The interpersonal side of collaboration is discussed through a different lens in more details here.
Martin Fowler's book gave a precise name to something developers already did informally — and the precision turned out to matter.
A code smell isn't a bug. It's a pattern that correlates with deeper problems often enough to be worth a second look.
Ward Cunningham's financial metaphor for imperfect code became one of software's most-used terms — and one of its most-abused.
“Leave the code better than you found it” sounds simple. The discipline is in how small “better” is allowed to be.
The line about naming being one of the two hard problems in computer science gets repeated as a joke. The underlying difficulty is real and specific.
Most code review advice focuses on tone. The more useful question is what a review is actually supposed to catch that other steps don't.
DRY is one of the most quoted principles in software engineering, and one of the most commonly over-applied.
Michael Feathers' definition of legacy code has nothing to do with age — and that reframing is what makes the advice around it useful.
The five SOLID principles are widely cited and unevenly understood. Some hold up better under scrutiny than others.
The 1994 book gave recurring design problems shared names. What it didn't do is make every pattern equally worth using today.
John Ousterhout's book names complexity itself, rather than any specific bad practice, as the thing software design is actually fighting.
Most architectural advice is really about optimizing two underlying properties. Naming them directly makes the trade-offs clearer.
The industry conversation often treats this as a question with a right answer. It's really a question with a right answer for a specific system, at a specific size, at a specific time.
Fred Brooks' 1975 book made an observation about software project management that's still cited, and still routinely ignored.
A 1967 observation about organizations designing systems that mirror their own communication structure still predicts a lot about modern software.
Eric Evans' central argument is that most software problems are modeling problems in disguise — and the model deserves as much design attention as the code.
“You aren't gonna need it” sounds like an argument against planning ahead. It's actually an argument about where the cost of guessing wrong lands.
Jez Humble and David Farley's book argued that the safest way to ship software is to ship it constantly, in small pieces — the opposite of the intuition behind big, careful releases.
TDD's red-green-refactor cycle sounds like a small procedural detail. The order turns out to change what the resulting code looks like.
A simple shape — more unit tests than integration tests, more integration tests than end-to-end tests — explains a lot about why some test suites are fast and reliable and others aren't.
Two very different scheduling philosophies for the same underlying problem: deciding when a change is allowed to ship.
A good incident postmortem is a specific writing discipline, and the discipline matters more than most teams expect.
A feature flag looks like a simple if-statement. The idea underneath it separates two decisions that most software conflates by default.
Two developers working on one problem at one machine sounds like it should cost twice as much output. The real accounting is more complicated.
A widely cited claim in software engineering holds that a bug found in production costs far more to fix than the same bug found earlier. The reasons why are more specific than “it's just true.”
Two developers can honestly disagree about whether a task is done. A written definition exists to remove that disagreement before it causes a problem.
Andy Hunt and Dave Thomas's book is full of dated technical examples and a set of underlying habits that haven't dated at all.
Robert C. Martin's follow-up to Clean Code argues that professionalism in software isn't a personality trait — it's a specific, learnable set of practices.
The term gets used constantly in software culture. What it actually describes, and doesn't, is worth being precise about.
An RFC document is a specific writing discipline for a specific problem — getting a decision reviewed before it's expensive to change.
The tone advice around code review is well-worn territory. A few specific, concrete techniques do more than general kindness reminders.
Seniority in software is often described vaguely as “more experience.” What actually changes is more specific than that.
An estimate isn't just a number — it's the opening move in a negotiation most developers don't realize they're having.
Good mentoring isn't just answering questions faster than a search engine would. What actually transfers is harder to see and easier to skip.
Burnout in engineering culture gets discussed as an individual failure to manage stress. The research points more toward systemic causes.
A README is very likely the single most-read file in most repositories, and very likely the least deliberately written.
A well-designed API is mostly a set of small, consistent decisions. A poorly designed one is usually the sum of many individually reasonable exceptions.
A version number formatted as X.Y.Z looks simple. What each part is supposed to communicate is more specific, and more often violated, than most users realize.
Most technical documentation is written to be comprehensive. Most of it is read to answer one specific question, fast.
An error message is one of the few pieces of documentation a user reads exactly when they need it most — and most of them are written with almost no care.
A changelog is one of the cheapest documentation habits available, and one of the most commonly skipped.
A new developer's first week is often measured by how fast they ship something. What it actually should teach is broader than that.
Removing a feature safely takes more deliberate process than adding one — and most of that process is communication, not code.
The tools a team builds for itself rarely get the same design attention as the product it ships to customers. DX is the argument that they should.