The Reading List I Give Every Software Engineering Mentee

Every few months, someone I’m mentoring asks a version of the same question: “What should I be reading?”

For a long time I answered ad hoc — different books depending on what problem they were working through. But I kept recommending the same 40-odd books, and eventually I wrote them down. This is that list.

It covers eleven areas: software craft, systems, DevOps and engineering culture, product design, leadership, teamwork, communication, negotiation, business fundamentals, learning how to learn, and personal effectiveness. Not all of them are written for software engineers — several aren’t even about software. That’s intentional.

Learning to tie knots taught me about sewing; sewing connected to crocheting; both made friction and elasticity concrete in a way I now see everywhere — in why systems fail under load, in why certain abstractions hold and others slip. The design principles behind a well-made door handle — affordances, feedback, making the right action obvious and the wrong one hard — turn out to apply directly to building a database migration runner that engineers won’t misuse. The connection isn’t metaphorical. It’s the same problem.

The march of industrial automation changed medicine in a specific way: as tooling got more capable, doctors shifted from learning on the job toward longer formal training before they ever touched a patient. I think AI is doing the same thing to software engineering. The floor is rising. Breadth of foundation is becoming more valuable, and learning narrowly on the job is becoming less durable. The engineers who do well over the next decade will be the ones who built widely before the automation got good.

Niklas Luhmann published across law, economics, politics, and sociology not because he was a specialist in all of them, but because he kept finding the same patterns in different places. Charlie Munger called this building a latticework of mental models — and argued that the wider your lattice, the harder the problems you can solve. That’s why this list isn’t just software books.

The ⭐ markers are the books I’d insist on if you can only read one per section. Start with those.

This post contains Amazon affiliate links. If you buy through them, I earn a small commission at no extra cost to you.


A note on audiobooks

Most of this list is available on Audible, and honestly — that’s how I’ve gotten through the majority of it. A lot of these books are dense or dry, and cracking one open after a long day of engineering requires a kind of willpower that doesn’t always show up on demand.

Audiobooks change that calculus. Sixty percent retention while doing the dishes or mowing the lawn beats zero percent retention from a physical copy sitting on the nightstand. You’re not going to annotate High Output Management in the margins anyway — but you can finish it in four commutes and walk away with the mental model that matters.

The exceptions are the ones that genuinely reward slow reading and note-taking: Designing Data-Intensive Applications, Domain-Driven Design, How to Read a Book, and anything you’re reading syntopically alongside other books on the same topic. Those deserve dedicated focus and active note-taking — read them when you can sit down and engage, not while doing something else.

Everything else: put it in your ears and get on with your life.


Where to Start: A Reading Order

Before anything else, read these two back-to-back:

How to Read a BookHow to Take Smart Notes

How to Read a Book teaches you to read at four levels — most engineers never get past level two. How to Take Smart Notes gives you a system for retaining and connecting what you read. Together they change how you engage with everything else on this list. (Full context in the Learning & Knowledge Management section below.)

Then work by career stage:

Early career (1–3 years): The Pragmatic ProgrammerClean CodeThe Lean StartupThe Design of Everyday ThingsNever Split the DifferenceHow to Win Friends & Influence People

Mid career (3–7 years): Designing Data-Intensive ApplicationsAccelerateThe Five Dysfunctions of a TeamRadical CandorThe Manager’s PathMade to StickGood Strategy Bad Strategy

Senior / Staff / Lead: High Output ManagementAn Elegant PuzzleDomain-Driven DesignThe Mythical Man-MonthThe Effective Executive


Software Engineering: Core Craft

These books shape how engineers think about their work day to day.

The Pragmatic Programmer ⭐ — Andy Hunt & David Thomas

The single best book for early-to-mid career engineers. DRY, broken windows, tracer bullets, career investment. These principles predate Agile and have outlasted it. Start every mentee here.

Clean Code — Robert C. Martin

Establishes vocabulary and discipline for code quality: naming, functions, comments, TDD, code smells. Essential for engineers who want to be taken seriously in code review.

The Clean Coder — Robert C. Martin

Companion to Clean Code. Shifts focus from the code to the person writing it — saying no, estimating honestly, professionalism under pressure. Often overlooked; shouldn’t be.

A Philosophy of Software Design — John Ousterhout

A useful counterweight to Clean Code — argues against excessive decomposition and explores complexity as the root cause of software problems. Read this after Clean Code to sharpen your judgment.

Effective Software Testing — Mauricio Aniche

A developer’s guide to testing strategy: boundary analysis, structural testing, mocking, testability design, and when to apply each technique. More rigorous than the testing chapters in Pragmatic Programmer or Clean Code — read this when you want to go deeper than “write more tests.”

Head First Design Patterns — Freeman & Robson

Accessible entry point to GoF design patterns. Far more readable than the original Gang of Four book.

Patterns of Enterprise Application Architecture — Martin Fowler

The reference catalog for enterprise software design. Don’t read cover to cover — reach for it when you encounter a problem it names.


Systems & Scale

For engineers moving from writing code to designing systems.

Designing Data-Intensive Applications ⭐ — Martin Kleppmann

“The Wild Boar Book.” Definitive guide to databases, distributed systems, replication, consistency, and stream processing. Required for any backend engineer working at scale. Dense — take notes.

Accelerate — Forsgren, Humble & Kim

The only book on this list backed by peer-reviewed statistical evidence. Establishes DORA metrics. Proves speed and stability aren’t tradeoffs. Essential for senior engineers and tech leads.

The Mythical Man-Month — Frederick P. Brooks Jr.

Brooks’ Law: adding people to a late project makes it later. No Silver Bullet. Fifty years old and still accurate on team dynamics and communication overhead.

Domain-Driven Design — Eric Evans

Ubiquitous language, bounded contexts, aggregates. Essential for engineers building complex business software. Heavy — pair with Implementing Domain-Driven Design (Vernon Vaughn) as a companion.

Thinking in Systems — Donella Meadows

Not a software book, but the clearest explanation of how systems actually behave: stocks and flows, feedback loops, delays, and leverage points. Once you have this vocabulary you start seeing it everywhere — in distributed systems, in org design, in why software rewrites so often reproduce the problems they were meant to fix.

Database Internals — Alex Petrov

Where DDIA gives you the what and why of distributed data systems, Database Internals gives you the how: B-trees, LSM trees, storage engines, consensus algorithms, and distributed system implementation details. Read after DDIA when you want to go one level deeper.

SQL Performance Explained — Markus Winand

The book behind Use the Index, Luke . Explains how indexes actually work — B-tree structure, composite index column order, index scans vs. full table scans, and why ORM-generated queries are often slow. Short, dense, and more useful for day-to-day backend work than most database books.


DevOps & Engineering Culture

The books that change how engineering teams operate — how work flows, how failures get prevented, and why the best teams move fast without breaking things.

The Phoenix Project ⭐ — Gene Kim

Fiction that teaches DevOps principles through the story of a struggling IT organization. One of those books engineers pass around a team. Best read before Accelerate.

The Checklist Manifesto — Atul Gawande

Not a software book, but the most important book I’ve read about systematic verification. How checklists prevent failures in aviation, surgery, and construction. Directly applicable to deployment runbooks, incident response, and code review checklists.


Product & Design Thinking

For engineers who want to understand the “why” behind what they build.

The Design of Everyday Things — Don Norman

The foundational text on human-centered design. Affordances, signifiers, mapping, feedback loops, mental models. Changes how you see every interface you interact with.

The Lean Startup ⭐ — Eric Ries

Build-Measure-Learn. MVP. Validated learning. The mental model for shipping product under uncertainty. Read early — it changes how you frame every product decision.

Inspired — Marty Cagan

How successful tech companies actually build products. Empowered teams, product discovery, and the product manager’s role. The operating manual for product organizations.

Sprint — Jake Knapp

Practical methodology for rapid design and testing. Good for learning to move fast on hard problems with limited data.

The Lean Product Playbook — Dan Olsen

Practical companion to Lean Startup. Detailed process for finding product-market fit. Strong framework for product discovery work.


Leadership & Management

For engineers moving into tech lead, staff, or management roles.

The Manager's Path — Camille Fournier

The career map for engineering leadership — from senior IC to tech lead to engineering manager to VP. The most practical book for engineers entering management.

Radical Candor — Kim Scott

Care personally, challenge directly. The framework for giving honest feedback without being cruel. Changes how you run 1:1s and code reviews.

High Output Management ⭐ — Andrew Grove

Andy Grove’s masterwork on management as leverage. Output of a manager = output of their team. Meetings, decision-making, performance reviews. The management bible.

An Elegant Puzzle — Will Larson

Systems thinking applied to engineering management. Reorgs, technical debt, succession planning, organizational design. Written by someone who has managed at Digg, Uber, Stripe, and Calm.

The Effective Executive — Peter F. Drucker

Drucker’s classic on what effectiveness actually means. Know your time, focus on contribution, make strengths productive. Written in 1966 and still sharper than most modern management books.

The First 90 Days — Michael Watkins

The playbook for joining a new organization or taking a new role. How to accelerate through the learning curve, secure early wins, and build alliances.


Teamwork

The Five Dysfunctions of a Team ⭐ — Patrick Lencioni

Absence of trust → fear of conflict → lack of commitment → avoidance of accountability → inattention to results. The diagnostic pyramid for why teams fail. Written as a business fable.

Peopleware — DeMarco & Lister

The human side of software development. Environment, team jelling, and why most problems are sociological, not technological. Predates Agile but anticipated most of what it got right.

Death by Meeting — Patrick Lencioni

Why meetings fail and how to fix them. Short, practical, written as fiction like Five Dysfunctions.


Communication

Strong communication is the multiplier on every other skill.

How to Win Friends & Influence People ⭐ — Dale Carnegie

Foundational. Not manipulation — genuine interest in people, listening, making others feel valued. Read before any leadership role.

Crucial Conversations — Patterson, Grenny et al.

The framework for navigating high-stakes conversations: how to stay in dialogue when emotions run high. Essential for code reviews, incident retrospectives, and performance conversations.

Made to Stick — Chip & Dan Heath

Why some ideas survive and others die. Simplicity, unexpectedness, concreteness, credibility, emotions, stories. The framework for technical communication and engineering proposals.

Influence — Robert Cialdini

The science of why people say yes. Reciprocity, commitment, social proof, authority, liking, scarcity. Equally useful for understanding how you’re being influenced and how to persuade more effectively.

Nonviolent Communication — Marshall Rosenberg

The best book I’ve read on communication — for work, relationships, and marriage. Observations vs. evaluations, needs vs. strategies, requests vs. demands. Most conflict, once you apply this framework, turns out to be two people with unmet needs talking past each other rather than a genuine disagreement. It belongs on this list as a professional book, but honestly the personal application is just as significant. Buy a second copy for your spouse.


Negotiation

Negotiation is a daily activity for engineers — priorities, deadlines, scope, compensation. One book covers this better than any other I’ve found.

Never Split the Difference ⭐ — Chris Voss

Former FBI hostage negotiator. Tactical empathy, mirroring, labeling, the accusation audit. The most immediately practical negotiation book on the market.


Business Fundamentals

For engineers who want to understand how the business side works.

The Personal MBA — Josh Kaufman

A self-directed MBA in one book. Value creation, marketing, sales, operations, finance, and human behavior. The foundation for understanding how businesses work.

Good Strategy Bad Strategy — Richard Rumelt

Most strategy is “fluff” — goals masquerading as strategy. Real strategy is diagnosis + guiding policy + coherent actions. Sharpens your ability to recognize and contribute to actual strategic thinking.

Blue Ocean Strategy — Kim & Mauborgne

How companies create new market space instead of competing in existing ones. Good for product and platform engineers thinking about differentiation.

Value: The Four Cornerstones of Corporate Finance — McKinsey

How companies create value for shareholders — cash flow, return on invested capital, growth. Translates financial thinking to engineering decisions about build vs. buy, technical debt, and investment.

The Founder's Dilemmas — Noam Wasserman

Empirical research on how founding decisions determine startup outcomes. Co-founder conflicts, hiring, equity splits. Essential for engineers considering startup roles or founding a company.

Critical Business Skills for Success — The Great Courses

A lecture series covering strategy, finance, marketing, operations, and leadership in a format that’s easier to absorb than a textbook. Good for engineers who want a structured foundation in how businesses actually function without committing to a shelf of individual books. Available as audio — works well on a commute.

Poor Charlie's Almanack ⭐ — Charlie Munger

Mental models, multidisciplinary thinking, inversion, avoiding stupidity. Wide-ranging and genuinely fun to read — Munger’s collected speeches and commentary cover everything from psychology to physics to business, and the connections he draws are exactly the kind of cross-domain thinking the rest of this list is trying to build.


Learning & Knowledge Management

How you read and retain information determines how fast you grow. I put these first in the reading order — before the career-stage books — because they change how you engage with everything else.

How to Read a Book — Mortimer J. Adler & Charles Van Doren

Most people read the same way they learned to in school: start at page one, proceed to the end, close the cover. Adler describes four levels of reading, and most engineers never get past level two. The key insight is syntopical reading — reading multiple books on the same topic simultaneously and building your own synthesis. Every technical book on this list benefits from being read at the analytical level with a pen in hand.

How to Take Smart Notes — Sönke Ahrens

The book that formalizes the Zettelkasten system — developed by sociologist Niklas Luhmann, who published 70 books and 400+ papers using nothing but a box of index cards linked to each other. The core idea: a note that doesn’t connect to anything else is just storage. A note that links is thinking.

These two books are also the foundation of a practice I’ve written about separately: the Zettelkasten method — building a connected, permanent knowledge base where reading compounds instead of evaporates. That post covers the method itself, Logseq and Obsidian as tools, and Stelekit, a sync tool I built for managing my own vault: Building a Second Brain for Engineering Work →


Personal Effectiveness

Foundational habits and systems that amplify everything else.

The Power of Habit ⭐ — Charles Duhigg

The neuroscience behind habit loops: cue, routine, reward. Explains why habits form and how to change them at the mechanism level. Covers organizational habits too — useful for understanding why engineering teams repeat the same dysfunctions.

Atomic Habits — James Clear

The practical companion to Power of Habit. Where Duhigg explains the science, Clear gives you the implementation: identity-based change, habit stacking, environment design, the two-minute rule. Read Power of Habit first for the mental model, then Atomic Habits to act on it.


If I sent you here — start with the ⭐ books. Pick one from the section most relevant to where you are right now. Message me once you’ve finished it.

Structured Concurrency is a Footgun for Mixed-Experience Teams Building a Second Brain for Engineering Work

Metadata

Published:

2760 Words

13 minutes