Developer Thinking Frameworks

Joel Spolsky and Brian Kernighan. Spolsky writes for working developers about the everyday decisions that compound — what good developer experience looks like, why specs matter, how to spot a healthy codebase. Kernighan's Unix philosophy gives you a small set of composable rules for writing software that other people can read. Karpathy's lectures are excellent once you have the basics and want to understand modern AI engineering specifically.

Yes. Engineering thinking transfers cleanly to product management, design, and founding work. The Liskov substitution principle is a useful test for any abstraction. Torvalds's bug-tracking discipline maps onto incident reviews of any kind. Hamilton's mission-reliability framing is how senior operators think about uptime, supply chains, and regulatory exposure. The frameworks are about reasoning under technical constraint; that constraint shows up everywhere modern work does.

No. These frameworks describe how experienced developers think, which is useful scaffolding, but they can't substitute for the slow craft of reading and writing real code under feedback from someone who's seen more incidents than you have. Use them as discussion material with a mentor or as orientation when prioritising what to study; not as a syllabus that replaces the work.

The framework captures the thinking pattern, not the tone. Torvalds's technical judgement on kernel architecture is worth studying separately from how he writes mailing list replies; DHH's argument for conceptual compression stands whether or not you'd want to work with him. Separate the signal from the style — these files document the engineering reasoning, and we're explicit when an approach has interpersonal costs the person in question chose to absorb.