Readings
Developer Books – Reading Notes
🕒 Last updated: December 21, 2025
This is a list of books I’ve read over the years and found genuinely useful in my work as a software developer.
These are not summaries. Just short notes on why a book stuck with me and when it tends to be useful.
Domain-Driven Design: Tackling Complexity in the Heart of Software
by Eric Evans
Picked up to better understand how complex business domains can be modeled explicitly and how language, boundaries, and design decisions influence long-term system evolution.
Continuous API Management
by Mehdi Medjaoui
⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐ (10/10)
What stayed with me from this book is the idea that APIs should be treated as long-living products, not just technical artifacts.
It helped me think more clearly about ownership, evolution, and the cost of decisions that seem small early on but become hard to change later. Especially relevant in environments where APIs outlive teams and technologies.
Software Architecture: The Hard Parts
by Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani
⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐ (10/10)
This book resonated with me because it openly acknowledges that most architectural decisions involve trade-offs, not clean answers.
It’s useful once you’ve moved past searching for “the right architecture” and started dealing with real constraints: timelines, teams, existing systems, and organizational pressure. It helped me reason more explicitly about decisions I was already making intuitively.
Design It!
by Michael Keeling
⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐ (10/10)
I liked this book because it treats design as something that evolves continuously, not something you lock in early.
It aligns well with how real projects tend to work, where architecture needs to adapt over time and decisions are revisited as the system grows. It reinforced the idea that design is tightly connected to feedback and delivery, not just upfront planning.
A Philosophy of Software Design
by John Ousterhout
⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐ (10/10)
This book changed how I think about complexity and where it comes from in software systems.
Rather than focusing on specific techniques, it pushed me to pay closer attention to abstractions, responsibility boundaries, and how decisions accumulate over time. I don’t agree with every opinion, but it sharpened my sensitivity to design choices that silently increase complexity.
The Pragmatic Programmer
by Andy Hunt & Dave Thomas
⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐ (10/10)
This is one of the few books I keep mentally referencing regardless of the technology I’m working with.
It’s less about code and more about how you approach your work: ownership, responsibility, and continuous improvement. Many of its ideas are simple, but they compound over time, which is why the book stays relevant.
Don’t Make Me Think, Revisited
by Steve Krug
⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐ (10/10)
This book made me much more conscious of how people actually interact with software.
Even outside UI work, it reinforced the importance of clarity and intent. It’s a quick read, but the core idea — that unnecessary thinking is a design failure — stayed with me long after finishing it.
Patterns of Enterprise Application Architecture
by Martin Fowler
⭐⭐⭐⭐⭐⭐⭐⭐⭐☆ (9/10)
I mainly value this book for the vocabulary it provides.
It helped me put names on architectural concepts I had already encountered in practice but struggled to describe clearly. The more systems you’ve worked on, the more familiar the patterns start to feel.
Head First Design Patterns
by Eric Freeman, Elisabeth Robson
⭐⭐⭐⭐⭐⭐⭐⭐⭐☆ (9/10)
This book was an important first step for me in understanding design patterns and, more importantly, why they exist.
I still recommend it as an entry point because it makes patterns feel concrete and relatable, without requiring heavy theoretical background. It helped me build the mental model needed to recognize patterns in real code and later approach more formal material with confidence.
Clean Architecture
by Robert C. Martin
⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐ (10/10)
What I value most in this book is not the specific rules, but the way it forces you to think about boundaries and dependencies.
I don’t follow it dogmatically, but it consistently nudged me toward designs that are easier to reason about and maintain as systems grow.
Clean Code
by Robert C. Martin
⭐⭐⭐⭐⭐⭐⭐☆☆☆ (7/10)
This was one of the first books I read early in my career and, at the time, it helped set a baseline for readability and basic discipline.
Over time, I found that some of its guidance doesn’t age particularly well if followed rigidly. It’s still a useful read, but best treated as a starting point rather than a rulebook. The value lies in understanding the intent behind the advice, not in applying it blindly.