Coders at Work
Source: https://codersatwork.com/ ↗
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.
The result is an ethnographic window into how great programmers actually think: how they debug, how they read code, how they decide when to rewrite and when to patch.
No two of them agree on methodology, which is itself the most important finding.
For product leaders, the book dissolves the illusion that engineering excellence follows from process; it shows that craft is personal, contextual, and built over decades.
Read it to understand the people who build the thing you are directing.
Central argument
Seibel's central finding, emerging from fifteen long-form interviews with programmers of the caliber of Knuth, Norvig, and Frances Allen, is that there is no unified methodology underlying programming excellence. The disagreements between his subjects — on debugging approaches, on when to rewrite versus patch, on how to read unfamiliar code — are not noise to be averaged out but the actual signal: craft in software is irreducibly personal and context-dependent, accumulated over decades rather than installed through process. The implicit argument is that the search for a universal engineering methodology is a category error.
Critique
The sample is almost entirely male, Western, and drawn from a particular generational cohort that built systems in an era before cloud infrastructure, continuous deployment, and product-led development redefined what 'great programming' even means in practice. This creates a risk that the book romanticizes a form of individual, deep-craft expertise that was shaped by specific historical conditions — long compile times, scarce hardware, lone-genius problem-solving — that no longer fully describe the collaborative, fast-iteration environments where most software is built today. A thoughtful reader should ask how much of what these programmers attribute to personal craft is actually a product of the constraints that no longer exist.
Why it matters for product
For a product leader, the book's core finding — that engineering excellence is personal and contextual, not procedural — has direct implications for how you staff and structure teams: hiring for demonstrated craft and judgment rather than process compliance, and resisting the organizational reflex to solve quality problems by adding ceremonies. It also recalibrates expectations about what directing engineers actually means: if no two exceptional programmers agree on methodology, then a CPO's job is less about imposing a development philosophy and more about creating conditions where individual craft can operate at its highest level.