There are books that teach you how to write better code, and there are books that change how you think about what you are doing when you write code. The former category is large and mostly not worth recommending here because it dates quickly and because better resources than books exist for most of those purposes. The latter category is small, durable, and more useful over the course of a long career than any framework tutorial. This is a list from the latter category.
Begin with Gödel, Escher, Bach: An Eternal Golden Braid by Douglas Hofstadter. Hofstadter's book is about consciousness, self-reference, and the formal systems that give rise to them — but for software engineers it is also the deepest available account of what computation actually is. The strange loops, the self-modifying formal systems, the question of how a system can contain a representation of itself — these are not metaphors for programming. They are the foundational concepts, approached from a direction that makes their strangeness visible again. GEB asks what it means for a formal system to be expressive enough to describe its own limitations, and that question turns out to be central to understanding everything from compiler design to the halting problem. The book is 700 pages and demands patience; the patience is rewarded.
Zen and the Art of Motorcycle Maintenance by Robert Pirsig is relevant here for its sustained argument about what Quality in work actually means. Pirsig distinguishes between classical understanding — how a system works mechanically, what its components do — and romantic understanding — how a system feels, whether it is good, whether it is working as intended. Most software engineering culture is strongly classical. Pirsig argues that this is an impoverishment: that you cannot maintain something you do not care about, and that care requires a romantic engagement with the work as something that has standards beyond correctness. His mechanic who maintains his motorcycle by understanding it rather than by following a checklist is the craftsman analog to the engineer who understands their system rather than just operating it. The book is also partly a memoir of psychological crisis, and that dimension is not irrelevant to an audience working in an industry with documented burnout problems.
For decision-making under uncertainty — which is most of what senior engineering involves — Thinking, Fast and Slow by Daniel Kahneman is the best available map of how you will fail. Kahneman describes System 1 (fast, intuitive, associative) and System 2 (slow, deliberate, effortful) not as a helpful duality but as a site of systematic error: System 1 dominates most of our cognition, and System 1 is optimized for small-group social dynamics rather than statistical reasoning, large-scale system design, or probabilistic estimation. Engineers who understand the anchoring effect, the planning fallacy, the availability heuristic, and the overconfidence bias are better positioned to catch their own mistakes before they compound into production incidents. The book does not fix the errors it describes; it makes them legible, which is the necessary first step.
Csikszentmihalyi's Flow: The Psychology of Optimal Experience is directly applicable to the question of why some engineers are sustainably productive over decades and others burn out or plateau in their thirties. Flow states — deep absorption in a task where performance improves and time compresses — require a specific balance: the task must be challenging enough to engage full capacity but not so hard it produces anxiety. Csikszentmihalyi shows that this balance is a design parameter, not a fixed feature of the work or the person. Engineers who understand flow are better equipped to architect their own working conditions — to seek out the level of challenge that keeps them engaged, to recognize when they have become too junior for a role and need harder problems, to design collaborative structures that make flow more rather than less available to their teams.
Finally, John Williams's Stoner is not a book about software engineering. It is a novel about a man who spends his life in a single university, teaching literature, mostly unhappily, and dying without external recognition. I recommend it here because it is the most honest account I know of what a career actually is — not a set of achievements but a relationship you develop with your work over time, complicated by institution and politics and the gap between what you intended and what you accomplished. For engineers in their twenties who are still in the stage of treating career as a series of promotions to achieve, Stoner is an uncomfortable read. It asks what the work is actually for, and it insists on the question until you take it seriously. The answer Stoner arrives at is private and hard to articulate and completely sufficient. That is, I think, a realistic account of what a good career in engineering looks like from the inside.
None of these books will make you a better programmer in the short term. All of them will make you a clearer thinker about what you are doing over a long career, and that compounds in ways that technical knowledge alone does not.