Software Engineering

Not a book to read cover-to-cover — a book to know exists. Knuth began writing it in 1962 and is still at it, because he refused to publish anything he had not understood completely. The result is the definitive referenc…

One page that changed how software is written. Dijkstra argued that unstructured jumps make programs impossible to reason about — and that the quality of a programmer's thinking is bounded by the control structures avail…

Codd's 1970 paper proposed that data storage should be separated from its physical representation on disk and instead organized into relations — tables with rows and columns governed by mathematical set theory. At the ti…

The first book that treated programmers as psychological subjects rather than interchangeable resources, and programming teams as the primary variable of software quality. Weinberg introduced the concept of "egoless prog…

Wirth's method is deceptively simple: start with a high-level statement of what the program should do, then refine it step by step into executable code, making one design decision at each level. The paper walks through a…

The most influential paper ever written on software architecture, and it fits in five pages. Parnas demonstrated with a concrete example that the obvious way to decompose a system — along the steps of its processing — pr…

Brooks's 1975 book is famous for one idea — "adding manpower to a late software project makes it later" — but the larger argument is more interesting: software projects have an irreducible complexity and a conceptual int…

The father of Fortran, the first widely used programming language, used his Turing Award lecture to question everything he had built. Backus argued that conventional programming languages were prisoners of the von Neuman…

The paper that originated the concurrency model behind Go, Erlang, and large parts of Rust. Hoare proposed that parallel processes should communicate by passing messages through channels rather than sharing memory — an i…

The most useful collection of heuristics for designing systems — from the architect of the Alto at Xerox PARC and a Turing Award laureate. Lampson's hints ("do one thing at a time, and do it well," "use brute force," "ke…

Knuth's argument is radical and still undigested: a program should be written as an essay addressed to human readers, with the machine-executable parts woven in. Documentation and code are not two artefacts but one. The…

SICP shaped how an entire generation of MIT graduates thought about computation — not as a vocational skill but as a new way of expressing ideas. The book teaches programming through Scheme, a minimal Lisp dialect, and u…

Probably the most profound essay on what programming actually is. Naur argues that a program is not the code but the theory in the programmers' heads — the understanding of how the code maps to the real-world problem. Wh…

The companion to The Mythical Man-Month. Brooks distinguishes essential complexity (inherent in the problem) from accidental complexity (introduced by our tools and processes). His prediction — that no single technology…

Probably the most beautifully written book about what it feels like to program. Ullman, a veteran software engineer in 1990s San Francisco, writes about the seduction of code — the way proximity to the machine narrows yo…

Kernighan and Pike distil four decades of craft into a small book about what it actually means to program well: not writing clever code but writing code another person can read, debug and keep alive. Each chapter — style…

In this keynote at the 2000 ACM Symposium on Principles of Distributed Computing, Brewer conjectured that a distributed system cannot simultaneously guarantee consistency, availability, and partition tolerance — you must…

Helland, a veteran of Tandem, Microsoft, and Amazon, argues that as systems scale beyond a single machine, the classical guarantee of distributed transactions — where all parties agree atomically — becomes impractical or…

Vogels, Amazon's CTO, wrote this essay to explain why eventual consistency is not a compromise or a bug but a deliberate architectural choice driven by the realities of operating at planetary scale. He walks through the…

Fifteen long-form interviews with legendary programmers — Knuth, Norvig, Frances Allen, Crockford, Zawinski, Fitzpatrick, among others — conducted by a programmer who knows enough to ask the right follow-up questions. Th…

A free technical book on HTML5 written by Mark Pilgrim, a programmer whose reputation rests as much on the quality of his prose as on his code. Each chapter opens with historical context — the origins of the doctype, the…

An internal Google post, accidentally made public, in which Yegge compared Amazon and Google's approaches to internal architecture — and found Google wanting. The centrepiece is the "Bezos mandate": Jeff Bezos's decree t…

The standard book for the individual contributor-to-manager transition in technology companies, structured as a progression from mentoring an intern through managing a team, managing managers, and eventually running an e…

Kleppmann's book is the contemporary reference for understanding how data systems actually work — from the internals of B-trees and LSM-trees to the semantics of distributed consensus protocols. What distinguishes it fro…

Larson codifies the engineering management knowledge that was previously tribal — how to size teams, how to run migrations without halting feature work, how to handle organizational debt, how to design career ladders tha…

Levy's paper is part of the small research literature on why empathy should be taught in computer science programmes and what changes when it is. The piece is short, well-referenced, and argues the obvious point carefull…

A book about what senior individual contributors actually do in large organisations — the work that creates value when you no longer write most of the code yourself. Reilly, a principal engineer at Squarespace, describes…

Huyen writes the book that treats machine learning as an engineering discipline rather than a research project or business buzzword. The focus is on building reliable ML systems in production — data pipelines, model depl…

Ustynov takes a flat-footed but important observation and works it through with unusual patience: for sixty years, the conventions of software engineering — naming, design patterns, project layout, SOLID, logging formats…

Paul Vixie, the architect of BIND and cron, brings decades of systems programming experience to the question of how software evolves over time. His perspective on program state evolution likely addresses the fundamental…

The second-system effect — where teams rebuilding a successful system add every feature they previously held back — remains one of the most persistent pathologies in product development. If Coatta and Smith have identifi…