Ask HN: What books should I read to improve as a software engineer?
Recommendations for improving as a software engineer range from classic texts on design, architecture, and team dynamics to newer works on data-intensive systems, performance, and modern software design philosophy. Many contributors stress that books are most valuable when paired with hands-on experience—reading and writing real code, contributing to open source, and learning the underlying computer architecture. Several also argue for broadening beyond technical manuals to include writing, philosophy, and fiction to better understand users and collaborators.
Foundational software engineering & design books
- Strong support for general-principles books that shape how you think about code and projects, not specific tools.
- Frequently praised: works on software design philosophy, pragmatic day‑to‑day practices, classic essays on project management and team dynamics, and collections of programming “pearls.”
- Some recommend splitting reading into:
- “Why/how to design and deliver” (design philosophy, project planning, team dynamics).
- “What and how it works” (algorithms, data structures, compilers, interpreters, language‑specific “Effective X” style books).
Architecture, systems, and performance
- High enthusiasm for books on large-scale data systems and web application architecture; seen as essential for understanding databases, queues, and performance trade‑offs.
- Architecture overviews and integration-patterns books are recommended for higher‑level design.
- Systems and performance texts (CPU/memory behavior, OS, SRE, BPF tools) are valued for grounding engineers in how software really runs “on the metal.”
Controversial or polarizing titles
- One popular design book on “clean code” draws heavy criticism:
- Critics: leads to over‑abstracted, slower, harder‑to‑read code when followed dogmatically; ignores performance and hardware realities; spawns “Uncle says…” zealotry.
- Defenders: credit it with major personal improvement, but stress it must not be treated as a bible.
- Domain‑driven design is called both “fantastic” and “a waste of time”:
- Fans: useful for tackling complexity in business domains.
- Critics: confusing prose, unrealistic assumptions about stable terminology and available experts, too heavy for most real organizations.
- Even well‑known classics like the main “pragmatic” book and data‑intensive systems book receive some pushback as overrated or partly dated.
Beyond coding: people, UX, and thinking
- Strong endorsements for UX/interaction design books (e.g., about “everyday things”) as critical for anyone building tools humans use.
- Repeated praise for books on teams, workplaces, project failure/success, and organizational change.
- Recommendations for writing guides; good prose is seen as tightly linked to clear code and necessary for design docs and communication.
- Many advocate reading fiction and philosophy to build empathy, creativity, and broader life understanding.
Books vs practice
- One camp argues books alone won’t make you good; you must build things, read real code, and contribute to open source.
- Others counter that books on meta‑skills (problem‑solving approaches, heuristics) and thorough documentation can greatly accelerate learning—provided you don’t get stuck in theory.
- Widely shared view: combine all three—practice, reading, and reflection—while avoiding dogmatism and cargo‑culting any single book.