The Software Engineering Books I keep recommending
And what each one actually teaches you
People who know me are aware that I love books. I read them all the time and have a big bookshelf. Some ask me why, and the reason is twofold. First, it is a way to work (almost) directly with big names in our industry; second, this is my comparative advantage, as most developers don’t read.
Knowledge from the books gives me breadth and depth when discussing, deciding, and working with people and projects. And also in the AI world, it is even more important, so we can judge and guide AI properly.
When I look at the must-read book list, they are all the same. You will find books such as Clean Code, The Pragmatic Programmer, and DDIA. When people ask me to recommend books, I tend to add something more to those ones. I base my opinion on books I have used, talked about with colleagues, and already recommended in private.
Some of these books are really old, like 15-20 years or more, but they are still valid because they contain evergreen knowledge. But there are some new ones which I believe will become evergreen in the future. You will notice they are mostly tech-agnostic, so they can be relevant in many fields.
I grouped the books by the problem they solve. Because the right question isn’t “what should I read?” It’s “What am I struggling with right now?”
In 2024, I shared a long list of 30+ fundamentals that don’t change. This is the shorter, 2026 version: the books I still recommend, plus the AI and systems books that actually matter now.
So, let’s dive in.
Your team’s second brain. Now in Slack. (Sponsored)
Your engineers talk in Slack. They code in the terminal. Somewhere between those two things, context dies.
A bug is debated in #incidents at 2 AM.
An architectural call is made in a DM.
Every handoff leaks context, and every leak costs you. That’s the context tax - and your team pays it every day.
CodeRabbit Agent for Slack is built for agentic SDLC workflows. One agent for your entire Software Development Lifecycle, living in the channel where the work already happens. Your team keeps shipping while the agent maintains context.
How do you think about code
This group of books holds ones that keep the fundamentals of our job. They are the basis of good coding and the job of software engineers in general.
The Pragmatic Programmer by David Thomas & Andrew Hunt
I have recommended the book many times, and I will continue to do so. Some people think it is about coding, but it is more about the mindset than coding. When people ask me in our coaching sessions how to become better and more professional in their work, this is the book I recommend. It will teach you how to become responsible, avoid duplication, design for change, stay up to date with technology, and more. Now, there is an updated 20th-anniversary edition.
Check my short text about the book here.
Clean Code by Robert C. Martin
Widely considered one of the best books out there. It teaches you to code and structure it properly. What I liked about it was its approach to testing for creating high-quality code.
It didn’t age well, as some of its rules are now outdated. One example is to keep functions small, resulting in many small chatty functions. Yet there are still some valid concepts, such as good naming and testing, which are worth the price alone. The book is a good pair with the next one.
A Philosophy of Software Design by John Ousterhout
This is the book I wish I had read sooner. Why Clean Code is more focused on what to do, this book explains why complexity accumulates and how to fight it with abstraction and information hiding. It took me a while to understand why classes should be deep and interfaces simple and what “design it twice” really means.
Yes, this book is not perfect either. It embraces code comments and considers TDD harmful, but everything has its price.
If there’s one book on this list I keep coming back to, it’s this one. Essential if you’re working on a large codebase or moving into a senior role.
Check my full book review here.
Engineering Laws & Principles
Laws of Software Engineering by Dr. Milan Milanović
Yes, this is my book, which I released in April 2026 after two years of writing. It covers the gap that none of the other books do.
Every engineer will learn these laws eventually during their career. You will notice Brooks’ Law when you understand that your software architecture is the same as your organizational structure. When you try to rewrite software and fail, you will hit Gall’s Law. Goodhart’s Law is the idea that when you hit defined metrics, your product and organization are still worse than before.
The thing is that no one is teaching you these lessons systematically. You learn them by hearing them from your colleagues, in post-mortems, and when you make painful mistakes.
This book collects 63+ empirical laws and principles across seven areas:
Architecture & Complexity
People & Teams
Time & Planning
Quality & Maintenance
Scale & Performance
Coding & Design
Decision-Making & Biases
Each law covers what it says, where it came from, when it applies, and what it looks like on a real project. Forewords by Dr. Rebecca Parsons (CTO Emerita, Thoughtworks) and Addy Osmani (Engineering Director, Google Cloud AI). Reviewed by engineers from Google, Amazon, Uber, Oracle, and others.
Architecture
In this group, we have some books I consider to be fundamentals that every senior software engineer or architect should read. You will get a breath of architects’ jobs with them.
Fundamentals of Software Architecture by Mark Richards & Neil Ford
For anyone learning about software architecture, this is the first book I would recommend. Inside, you will learn about: Architectural styles, trade-off analysis, fitness functions, and how to document decisions that will help you in the future.
Before this book, architecture felt like something more abstract than it is.
In the meantime, the authors released a new book called Head First Software Architecture, which is even more beginner-friendly. It teaches you software architecture in simple terms and a visually rich format.
Software Architecture: The Hard Parts by Neal Ford, Mark Richards, Pramod Sadalage & Zhamak Dehghani
This is the book I read when working on complex projects. Fundamentals give you the basics, but this book guides you through the complexities. Concretely, you will learn how to break apart the monolith, when each pattern can help, and how to properly balance tradeoffs for those patterns.
Check my full book review here.
Domain-Driven Design Quickly by Abel Avram & Floyd Marinescu
This book is a good entry point for learning about DDD before you dive into Evans’ original 500-page book. It offers clear writing, a real worked example, and a solid introduction to hexagonal architecture. I recommend reading this first.
Systems & Data
In this group, we have books that help you gain a deep understanding of data and distributed systems.
Designing Data-Intensive Applications, 2nd Edition by Martin Kleppmann & Chris Riccomini
This is the second edition of the famous DDIA book, which is probably the most referenced book in software engineering. It was released as an ebook and in print this year in March. This edition builds on it with new coverage of AI data systems and new distributed system patterns. It’s almost 700 pages, and yes, it’s not easy to understand everything, but it’s worth it. As a senior engineer, you will tackle many of these issues in your job.
Check my full review of the first edition here.
Understanding Distributed Systems by Roberto Vitillo
If you need the first book to learn about Distributed Systems, this is the book for you. The book is easier to understand than DDIA, especially for those early in their careers. What stands out is that it covers the major topics of distributed systems in an understandable way for everyone, which is its main strength. You will learn about communication, APIs, coordination, transactions, scalability, resiliency, and more. Strongly recommended.
It was a joyful reading during my holidays.
AI Engineering
This is a new section with books on building AI-based solutions, mostly from the last few years. They help design systems that are reliable and maintainable when having LLM in the loop.
The Hundred-Page Language Models Book by Andriy Burkov
If you want to really understand how LLMs work, this is the right book. Burkov builds from ML basics through RNNs to transformers, with Python code and Jupyter notebooks at every step. Foreword by Tomáš Mikolov, one of the original creators of word embeddings. Burkov is the author of the even more famous book “The Hundred-Page Machine Learning” book.
It is available free to read at thelmbook.com.
AI Engineering by Chip Huyen
While Burkov’s books are mostly tied to theory, in this book, Huyen moves into production reality. The book talks about: model selection, evaluation, MLOps, multi-agent systems, and scaling. It is probably the best guide to build AI applications.
Testing
Even though I recommended a few books in this category, this time I decided to be only one.
The Art of Unit Testing by Roy Osherove
The book describes unit testing, which is crucial for developers to make high-quality software. It goes into details on how to write unit tests, how to scope them, and what to unit test. It will help you not only catch bugs but also survive refactorings and properly hit coverage numbers. The third edition covers modern languages and tooling.
Practices & Delivery
Accelerate by Nicole Forsgren, Jez Humble & Gene Kim
The book, which is built on research and examines what makes successful technology organizations different from others. Authors identified four metrics: deployment frequency, lead time, change failure rate, and mean time to recovery. They are called DORA metrics, and they still remain the best proxy for engineering team health. Read it before any conversation about productivity.
Refactoring by Martin Fowler
Yes, that Refactoring book. This is one of the most important ones, as it addresses how to change existing systems rather than build new ones. Changing existing systems is something we do more often than others. Refactoring is the process of changing a software system without altering its external behavior while improving its internal structure.
In the 2nd edition of the book, the author used JavaScript instead of Java, which was used in the 1st edition.
Career
The Software Engineer’s Guidebook by Gergely Orosz
It was a rare thing for someone to write a book for a software engineer’s career. This is something that we usually must learn from our own experience and the experiences of others. Gergely changed that when he wrote this book. It will help you grow from junior to staff, navigate performance reviews, and become a more effective individual contributor.
It is an Amazon #1 bestseller, now in 6 languages and 8 editions. Gergely runs The Pragmatic Engineer newsletter, which is probably the best newsletter in the industry.
Deep Work by Cal Newport
This is not a software book, but it can help you a lot in your career. The author writes that the ability to focus intensely on hard problems for an extended period is valuable. This skill separates great engineers from good ones.
The book discusses how to improve learning performance and offers concrete strategies to do so.
Where to start
Pick the book that matches where you’re stuck right now:
Now I wonder, what’s one book that changed how you think about software, not just how you write it? Reply and let me know. The best answers will be included in a future issue. And if this list was useful, forward it to one engineer who’d appreciate it.
Want to advertise in Tech World With Milan? 📰
If your company is interested in reaching founders, executives, and decision-makers, you may want to consider advertising with us.
Love Tech World With Milan Newsletter? Tell your friends and get rewards.
Share it with your friends by using the button below to get benefits (my books and resources).