The Practice of Programming
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, algorithms, design, interfaces, debugging, testing, performance, portability, notation — reads like the counsel of an artisan who has seen too many programs turn into dead weight and wants to name what separates the ones that survive.
The elegance is in the economy: no advice without an example, no example without consequence.
For product direction it is a reminder that the internal quality of software is not a technical detail detached from the product — it is what decides whether the product can keep evolving when reality shifts.
The Unix tradition at its clearest: do the simple things well before aspiring to the complex.
Central argument
Kernighan and Pike argue that programming excellence is not a matter of cleverness or sophistication but of disciplined simplicity: code should be written so that another person can read it, debug it, and extend it without requiring its original author. Working through style, interfaces, algorithms, debugging, testing, and performance, they make the case that each of these domains is governed by the same principle — economy of means. The book's central finding is that programs fail not because their authors lacked intelligence but because they optimized for the wrong moment, writing for the machine or for their own satisfaction rather than for the human who inherits the work.
Critique
The book's commitment to the Unix tradition is also its constraint: its examples, idioms, and mental models are drawn from a systems-programming world of C and command-line tools, which means the advice travels unevenly into contemporary contexts — distributed systems, dynamic languages, cloud-native architectures, or large-scale collaborative codebases with thousands of contributors. More substantially, the artisan framing assumes a relatively stable relationship between programmer and codebase that modern delivery pressures — rapid iteration, high team turnover, AI-assisted generation — have complicated in ways the book cannot address. A thoughtful reader might ask whether 'simplicity' remains a sufficient principle when the primary challenge is not individual craft but coordinating quality across organizational scale.
Why it matters for product
For a CPO, the book's core argument reframes internal code quality from a technical preference into a strategic constraint: if the software cannot be read, debugged, and extended by the team that inherits it, then the product's capacity to respond to shifting market conditions degrades regardless of roadmap ambition. This connects directly to delivery speed and organizational design — teams that inherit opaque, over-engineered systems spend their cycles deciphering rather than building, which is a product leadership problem before it is an engineering one. The principle that no advice should exist without an example and no example without consequence is also a useful standard for how product direction itself should be communicated: specificity and accountability over inspiring abstraction.