Structure and Interpretation of Computer Programs
Source: https://mitpress.mit.edu/sites/default/files/sicp/index.html ↗
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 uses it to build interpreters, simulators, and compilers from first principles.
Every chapter demonstrates that abstraction is the central intellectual activity of computing, not syntax or frameworks.
The full text is legally free online, which makes ignoring it a choice.
For product people who want to understand what their engineers actually do when they are doing it well, SICP remains the clearest window into the craft.
Central argument
Abelson and Sussman argue that programming is not primarily about instructing machines but about constructing and manipulating abstractions — a fundamentally intellectual activity closer to mathematics than to craft. Using Scheme as a minimal substrate, they demonstrate that a small set of compositional principles (procedures, data abstraction, streams, interpreters) is sufficient to build arbitrarily complex systems, including the very tools used to evaluate programs. The central thesis is that mastery of computing means mastery of abstraction: the ability to name, layer, and control complexity rather than memorize syntax or frameworks.
Critique
SICP's insistence on Scheme as the universal substrate, while pedagogically elegant, quietly assumes that the value of programming lies in its most reducible, formal properties — which risks underweighting the messy sociotechnical realities of large-scale software: team coordination, legacy systems, organizational constraints, and the political economy of technical decisions. The book treats computation as an essentially solitary intellectual act between a programmer and a problem, leaving almost no room for the collaborative, incremental, and often compromise-driven nature of how software is actually built and maintained at scale. A thoughtful reader might argue that this framing, however clarifying, produces a kind of abstraction fetishism that can make skilled engineers poor collaborators.
Why it matters for product
For a CPO, SICP reframes the persistent tension between product speed and engineering quality: when engineers resist shortcuts or push for refactoring, they are often defending the integrity of abstraction layers that keep future change possible — understanding this makes those conversations navigable rather than political. The book's model of layered abstraction also maps directly onto platform and architecture decisions: whether to build on leaky third-party APIs, whether to consolidate microservices, whether a team owns a coherent domain or a pile of incidental complexity. A product leader who internalizes SICP's argument can distinguish engineers doing genuine design work from those merely adding indirection, which is a rare and consequential form of technical judgment.