Reading widely — not just tech books — made me a measurably better engineer. Here's which books, why they mattered, and the unexpected connections to software.
The best book I read last year for becoming a better engineer was neither a programming book nor a computer science textbook. It was "Clear Thinking" by Shane Parrish — a book about decision-making.
Clear thinking maps directly to clean code. When I stopped writing code and started writing readable instructions for future collaborators (including future me), my PR approval rate jumped and code review comments dropped to near zero.
The fiction surprised me most. Reading novels — especially ones with complex narrative structures — improved my ability to hold multiple competing concerns in mind simultaneously. This is exactly what you do when debugging a complex distributed system.
Other books that unexpectedly made me better at engineering: "The Design of Everyday Things" by Don Norman (shaped how I think about API design), "Thinking in Systems" by Donella Meadows (changed how I approach architecture), and "Deep Work" by Cal Newport (gave me language to defend focused time).
The technical books that genuinely moved the needle: "A Philosophy of Software Design" by John Ousterhout (the best book on software complexity I've read), "Designing Data-Intensive Applications" by Martin Kleppmann (essential for backend engineers), and "The Pragmatic Programmer" (still relevant 25 years later).
The reading habit itself is the meta-skill. One book per fortnight is achievable for most engineers if you replace 30 minutes of doomscrolling with reading. The compounding effect over years is profound.