The Best Books for Programmers
(updated 2024)
May 25, 2023In this article, I’ve compiled a list of the best software engineering books.
The lists contains book about software design, object-oriented design, software development and software testing.
You might also be interested in books about Java in particular.
If you're looking for something more relaxing, you'll find some novels for nerds here.
Books for programmers are rarely suitable as audiobooks, as they often contain coding examples and complex diagrams. Fortunately, there are a few exceptions. Therefore, I also indicate for each book whether it is suitable and available as an audiobook.
(Disclosure: As an Amazon Associate I earn from qualifying purchases.)
The Pragmatic Programmer: From Journeyman to Master
by Andrew Hunt and David Thomas
This book contains concentrated, practical experience from several decades of programming practice. It presents the best practices and the major pitfalls of many aspects of software development concisely and with numerous practical examples. The focus is on creating high-quality, i.e., working, flexible, reusable, and maintainable code.
The book is suitable for both beginners and advanced programmers.
Beginners find valuable knowledge in this book that would otherwise take them years or decades to build up through their own experience (although the book cannot replace that experience, of course).
Advanced programmers can find their own experience in this book in a structured form, consolidate and deepen it – and most probably take some additional tips with them.
In addition to numerous anecdotes and analogies, each section contains practical exercises, with solutions at the end of the book. A book that every programmer should read.
Suitable as an audiobook? No, due to numerous code examples and exercises.
Clean Code: A Handbook of Agile Software Craftsmanship
by Robert C. Martin
This classic software development book is, as the name suggests, about clean code: Code that not only works but, above all, is easy to read and maintain.
This includes:
- meaningful names,
- short functions that perform one task at a consistent level of abstraction,
- meaningful (or no) comments (as opposed to comments that merely repeat what the code does, or worse, what it did once upon a time),
- a consistent code style,
- a clean class structure (this point is covered in more detail in the previously mentioned "Agile Software Development: Principles, Patterns, and Practices")
- error handling that does not obfuscate the actual business logic,
- unit tests, optimally test-driven in origin.
The principles presented are elaborated through several concrete Java case studies.
The book is easy to understand and entertaining to read through occasional anecdotes. Every developer should read this book and make the principles presented second nature.
The chapter on concurrency is unfortunately enormously simplified (without pointing this fact out). Modern optimizations such as instruction reordering and CPU cache effects are not addressed. Thus, after reading this chapter, the reader can quickly believe in deceptive security and produce subtle bugs that are hard to find afterward.
To gain confidence in writing concurrent applications, I highly recommend Brian Goetz's "Java Concurrency in Practice” to any Java developer.
Finally, a personal tip about code style: Don't make up your own style. Save yourself the countless discussions in your team and instead use an existing, widely used style for which there is documentation, checkers, formatters, and IDE plugins. A good example is Google's Java Style Guide and the associated tools.
Suitable as an audiobook? No! Even though this book inexplicably exists as an audiobook, it is not suitable as such due to the numerous code examples.
Design Patterns: Elements of Reusable Object-Oriented Software
by Erich Gamma, Richard Helm, Ralph E. Johnson, John Vlissides
Every programmer should actually have read this classic. “Actually,” because it is written in a very academic style and therefore difficult to read – especially if you’re a non-native speaker and read it in the original English edition.
It describes some of the most relevant design patterns (if not the most relevant ones of all) and their relationships with each other in great detail.
You’ll notice that the book is already 25 years old: the code examples are partly outdated from today’s point of view, and they entirely ignore newer aspects like concurrency. Nevertheless, every programmer should have this work on his bookshelf and know, recognize, and apply the classic 23 design patterns.
If you prefer something more practical, I recommend the online course “Java Design Patterns” by Dr. Heinz Kabutz, author of the well-known JavaSpecialists’ newsletter.
Suitable as an audiobook? No, due to numerous code examples and diagrams.
Clean Architecture: A Craftsman's Guide to Software Structure and Design: A Craftsman's Guide to Software Structure and Design
by Robert C. Martin
According to Uncle Bob, good architecture is characterized by the fact that software can be adapted to new and changing requirements with minimal effort – and thus has a long and profitable life.
First, the book gives an introduction to the basic principles of software design (SOLID principles), principles of component design (cohesion and coupling), and metrics for evaluating the design (Efferent and Afferent Coupling, Instability, Abstractness). All of the principles and metrics were described by Uncle Bob back in 2002 in "Agile Software Development: Principles, Patterns, and Practices"; for the most part, complete sections were simply copied.
The focus of the book is on the deduction and description of what Uncle Bob calls the "Clean Architecture":
At the software's core are the domain-oriented components, such as entities and use cases. Those are clearly separated from so-called "secondary components" – technical implementation details such as databases, user interfaces, or frameworks. All dependencies flow from the technical details to the core. This is achieved by Dependency Inversion at the component borders.
Decoupling makes it easier to test components. Technology decisions (such as which persistence technology or dependency injection framework to use) can be postponed – or revised relatively easily later in the project.
Numerous practical examples help to understand the theory. And like all of Uncle Bob's books, this one is peppered with numerous anecdotes from the author's professional life – all the way back to the 1970s. These anecdotes are not only entertaining, but also help to understand the long evolutionary path to modern software architecture.
All software architects and programmers should have read "Clean Architecture" – not only to implement modern software architectures – but also to understand the theoretical foundations behind it.
Suitable as an audiobook? No, due to numerous diagrams and code examples.
By the way, you can find a tutorial series on hexagonal architecture (which is almost identical to clean architecture) in the software craftsmanship section of this website.
Refactoring: Improving the Design of Existing Code
by Martin Fowler
With this classic software development book, Martin Fowler introduced in 1999 the topic of "refactoring", which was already known in the SmallTalk community then, to a broad developer community.
The book first describes the basic principles of refactoring and illustrates them with an introductory example.
The motivation for refactoring is usually a "code smell", i.e., code that works but is difficult to read and maintain. By naming and describing widely used code smells, Fowler also brought them to the attention of the developer community.
The largest part of the book comprises the catalog of over 60 refactorings. For each refactoring, the author describes the motivation (i.e., the situation in which it is to be applied), explains the functionality step-by-step, and demonstrates it vividly using JavaScript code examples.
This is where the changes in the second edition become clear: Fowler has not merely superficially polished the book but has extensively updated the entire catalog. Thus, he has renamed, consolidated, added refactorings, and replaced the Java examples with JavaScript variants. He provides appropriate notes where differences arise from using weakly vs. strongly typed programming languages.
Refactoring is not light reading (I had to keep pausing at the advanced refactorings) – yet I consider it a timeless must-read for all software developers.
For beginners, it is an excellent introduction to the subject. And professionals, for whom refactoring has been part of the TDD cycle for years and who know every refactoring shortcut in their IDE by heart, will learn a new refactoring or two – or find that refactorings they've done intuitively also have a name and a formal process.
Suitable as an audiobook: No, and fortunately, it is not available as such.
Domain-Driven Design: Tackling Complexity in the Heart of Software
by Eric Evans
In his classic work, Eric Evans describes a groundbreaking approach to software development, at the heart of which is an object-oriented model, representing, as accurately as possible, the domain model – that is, the (usually not formally defined) model used in the business departments of a company.
The development and maintenance of such a model require close cooperation between IT and business departments. Establishing a shared, unambiguous language – the "ubiquitous language" – enables communication without ambiguities and misunderstandings.
The domain model and close collaboration ultimately lead to an application that does precicely what the business department hoped it would do – and that can be easily adapted to new requirements.
Supported by numerous rich examples, the book shows a systematic path from the business requirements to the detailed technical model. It draws from a repertoire of technical building blocks – such as entities, value objects, aggregates, services, repositories, and factories – as well as higher-level concepts such as bounded context and context map, shared kernel and anticorruption layer, and core and subdomains, to name just the best-known.
The book is one of the most important in software development and is still cutting-edge after two decades. However, it is not an easy read – ideally, you should have a few years of programming experience and take a few weeks to work through it. The time and effort invested will be worth it and will lift you to a new level of software development.
Suitable as an audiobook: No.
Implementing Domain-Driven Design
by Vaughn Vernon
In “Implementing Domain-Driven Design,” Vaughn Vernon takes the reader on a journey with a fictional development team putting a software project into practice using Domain-Driven Design. In addition to strategic design (domains, subdomains, bounded contexts, context maps) and tactical design (entities, value objects, services, modules, aggregates, factories, repositories), he also explores software architectures that combine well with Domain-Driven Design (such as hexagonal architecture, CQRS, event-driven architecture, event sourcing).
Just like in real life, the developers make mistakes and learn from them. This helps the reader understand on many occasions why the initial extra effort of Domain-Driven Design pays off in the long run.
The book is a great complement to Evans’ classic, “Domain-Driven Design,” and has particularly helped me understand the relationship between bounded contexts, core domain, supporting subdomains, and generic subdomains. (It’s important to mention that you don’t need to have read Evans’ book as all concepts are explained from scratch in this book as well.)
The principles are explained through practical, detailed, and easily understandable examples implemented in Java (and partly Spring). I regularly use this book (along with “Get Your Hands Dirty on Clean Architecture”) as a reference.
Just like with Evans’ classic, you should dedicate sufficient time to study the book thoroughly. I recommend it to anyone who wants to apply Domain-Driven Design in practice successfully.
Suitable as an audiobook: No.
Domain-Driven Design Distilled
by Vaughn Vernon
With “Domain-Driven Design Distilled,” Vaughn Vernon delivers a compact summary of his bestseller “Implementing Domain-Driven Design” (hereafter: IDDD).
On 158 pages, the book explains in a very condensed way the essential concepts of DDD: bounded contexts, ubiquitous language, subdomains, entities, value objects, aggregates, and events.
As a bonus, it includes a detailed description of the modeling technique “Event Storming” (which is not covered in IDDD).
The book is suitable for quickly learning the basic concepts of Domain-Driven Design. I recommend it as an introduction and to establish a shared vocabulary for domain experts and managers.
For software developers who want to implement DDD in practice, the book is not in-depth enough; therefore, I would instead advise developers to read “Implementing Domain-Driven Design” or Evans’ classic “Domain-Driven Design” and read this book as a refresher a few months later.
Suitable as an audiobook: No.
Get Your Hands Dirty on Clean Architecture: A hands-on guide to creating clean web applications with code examples in Java
by Tom Hombergs
What is hexagonal architecture? What are its advantages? And how do you implement a hexagonal application in Java? Tom Hombergs answers these questions in "Get Your Hands Dirty on Clean Architecture".
The author first describes the problems of the classic layered architecture and explains how the "Clean Architecture" described by Robert C. Martin and the "Hexagonal Architecture" introduced by Alistair Cockburn (which is comparable in principle) can better meet the requirements of a modern application (maintainability, adaptability, extensibility) – namely by placing the business domain (and not technical details) at the center of the architecture.
After a short theory follows the practice: Step by step, the author develops an exemplary Java application with entities, use cases, ports, and adapters. He presents different mapping strategies for the adapters and discusses their advantages and disadvantages.
He details how to cut and test components and proposes a package structure that makes the architectural style visible.
After all application components are finished, the author shows how they can be assembled – firstly with pure Java and secondly using the Spring Framework. Thus, he impressively demonstrates that even the implementation of dependency injection can be merely an interchangeable detail of the software.
After that, the author shows how the application can be modularized using separate build artifacts, e.g., Maven modules, so the architectural style cannot be easily bypassed. Unfortunately, the author does not address how the Java module system could also perform this task.
Finally, he discusses what shortcuts we can take when mapping between layers and what technical debt we need to be aware of.
The book is excellently structured and written understandably and concisely throughout. The author has managed to fit into just 138 pages what takes up more than four times the space in "Designing Hexagonal Architecture with Java" (a book I do not recommend and therefore do not list here). An outstanding achievement!
Suitable as an audiobook? No, due to numerous diagrams and code examples.
By the way, you can find a tutorial series on hexagonal architecture in the software craftsmanship section of this website.
Working Effectively with Legacy Code
by Michael C. Feathers
Tests are important. And Test-Driven-Development leads to well-tested, well-structured software. Of course, every programmer knows that nowadays. Unfortunately, this has not always been the case. And so, we are often faced with the challenge of working on a system without tests – a "legacy system" by Michael Feathers' definition.
But how do we proceed if we don't have test coverage to ensure that our changes don't break anything? And if, on the other hand, we can't write these tests because the code is too complex, contains far too many dependencies, and logic and presentation are intertwined?
What can we do if we can't instantiate the class under test because we have to pass an object to its constructor that we can't easily create? Or if the method under test accesses the database – even though that database access isn't necessary for the functionality we want to test?
This book contains a catalog of mechanisms to locate and break these dependencies. And to consequently modularize the code, creating module boundaries – so-called "seams" – where we can apply our unit tests.
The presented strategies allow you to make changes with minimal risk. Today, using the refactoring features of modern IDEs, you can perform many of these changes fully automated. These changes allow you to implement initial tests. And based on these, you can perform more far-reaching refactorings that ultimately transform the codebase into a better design.
The author explains all strategies using excellent, real-world examples, written primarily in Java and C++.
Unfortunately, the book has not been updated in 15 years. In particular, inexperienced programmers should take care not to implement every strategy dogmatically. For some mechanisms, there are better alternatives nowadays; some practices lead to worse, instead of better code; and the issue of thread safety – a core issue in most enterprise applications today – is entirely left out.
For example, these days, you don't need an interface for every class you want to mock. Mockito can easily mock classes, i.e., resolve dependencies without extracting an interface. And if you do extract an interface, please follow the Interface Segregation Principle! The author's statement, "it's nice to have an interface that covers all of the public methods of a class" (p. 366), is unfortunately in stark contradiction to this.
Invoking abstract methods from a constructor ("Extract and override factory method") is better avoided if you don't want to suddenly be faced with an object that is only partially initialized. It is for good reason that C++ forbids this practice. Fifty-five pages after the introduction of this strategy, the author finally advises against its use in Java.
Multithreading is not a topic in almost any of the older classics. Nowadays, no programmer can get around it. If you extract a class using strategies such as "Break Out Method Object", you should, therefore, add a hint that the class is not thread-safe. (Alternatively, you can protect instance variables by suitable lock mechanisms).
Despite the age-related weaknesses mentioned, I can recommend the book to any programmer who has to work with legacy code. Experienced programmers have certainly used one or the other strategy intuitively before. Other techniques may be new. Either way, the formalization helps to reinforce the strategies, and their names improve team communication.
Just keep two things in mind: the book is 15 years old, and there is an exception for every rule!
Suitable as an audiobook? No, due to numerous code examples.
Extreme Programming Explained: Embrace Change
by Kent Beck and Cynthia Andres
In this landmark classic from 1999 and 2005 (2nd edition fully revised with insights from five years), Kent Beck introduces the "Extreme Programming" he developed.
What sounds like common sense to today's software developers was revolutionary at the time and fundamentally changed the way we develop software. XP has led us to build software with better quality, less time, reduced cost, and higher customer satisfaction than twenty years ago.
The book presents and explains the core values and principles of XP – which were radical at the time – and the practices used to put those core values and principles into action. These include user stories and incremental design, test-driven development, continuous integration with rapid builds and feedback, and pair programming.
What must have been an inspiring book for all programmers in the dawn of agile software development is still interesting today. It is a history book that takes us to a time when XP, the origin of modern agile methods, came into being.
Suitable as an audiobook? It would be suitable as an audio book but is not available as such.
The Programmer's Brain: What Every Programmer Needs to Know About Cognition
by Felienne Hermans
Felienne Hermans, a professor of computer science at Vrije Universiteit Amsterdam, explains in her book “The Programmer’s Brain,” supported by scientific findings from neuroscience, how the human brain works during complex tasks like programming, specifically when reading, understanding, and writing code, as well as learning a new programming language.
She describes how long-term memory, short-term memory, and working memory work together and the role of “chunking” (the process of grouping small units of information into larger ones, e.g., letters into words).
We learn why complex tasks, such as working with unfamiliar code, can lead to cognitive overload, and we discover concrete techniques grounded in cognitive science that can help us reduce cognitive load – both for ourselves and colleagues we are onboarding into new areas.
We also learn why “Clean Code” techniques, such as meaningful and consistent naming, short methods, and uniform formatting, are so effective.
The author uses easy-to-understand language and numerous practical examples from various programming languages to illustrate her points.
I recommend this book to programmers of all experience levels who want to improve their handling of complex challenges, especially those who want to understand how to avoid the cognitive overload often caused by complex tasks.
Suitable as an audiobook? No, due to numerous code examples.
The Clean Coder: A Code of Conduct for Professional Programmers
by Robert C. Martin
An exceptional programmer does not equate to a professional.
In "Clean Coder," software expert Robert "Uncle Bob" Martin describes the mindset and behaviors beyond writing code necessary to become a professional programmer.
He shares plenty of practical advice for both beginners and advanced programmers, such as:
- How to behave professionally under pressure?
- How do you react when your boss demands that a task be completed faster than you think is possible?
- How can you reliably estimate effort?
- Which tests should one write, and when?
- How do you behave professionally towards your teammates?
You can tell that the author draws from a hard-earned wealth of experience. But you don't always have to agree with him.
For example, I don't think the flow state has more disadvantages than advantages. I can also get into the flow during pair programming. And it's OK to find a solution alone in flow and then reprogram it in pair.
The book contains many personal, entertaining anecdotes from Bob's long career. For younger readers, though, the stories from the 60s and 70s, when people still worked with punch cards and teleprinters, might be a bit too antiquated ;)
A must-read for anyone who wants to call themselves a software professional.
Suitable as an audiobook? Yes! This is one of the few programming books about practices beyond the actual code. You won't find a single line of source code or a single UML diagram in this book. It is therefore absolutely suitable as an audiobook.
Clean Agile: Back to Basics
by Robert C. Martin
In February 2001, 17 programmers – among them Robert C. Martin, a.k.a. Uncle Bob – met to bring various lightweight software development processes (XP, Scrum, and others) to a common denominator. The result was the now-famous Agile Manifesto.
But what many call "agile" these days – with its excessive focus on process but neglected technical practices – is a far cry from what the creators had in mind back then.
The mission of this book is to get the facts straight and provide an overview of the original agile views, ideas, values, and principles.
Uncle Bob writes – as always – casually and entertainingly, rounding out the historical narratives with numerous personal anecdotes.
A definite recommendation for any programmer.
Suitable as an audiobook? Yes! There is not a line of code in the whole book and only two exemplary diagrams: a velocity and a burn-down chart. You can quickly google both of them.
Clean Craftsmanship: Disciplines, Standards, and Ethics
by Robert C. Martin
In his latest book, Uncle Bob teaches us the basic practices and principles of software craft that every professional programmer should know and follow.
The book consists of three parts:
Part 1, "Discipline", describes five core disciplines of Extreme Programming (XP): test-driven development (TDD), refactoring, simple design, pair programming, and acceptance testing.
TDD takes up almost half of the book. Uncle Bob lets us look over his shoulder as he solves test-driven several katas (also available as videos).
Part 2, "Standards", is about how to continuously balance high productivity with stable quality; it's about effort estimates in the form of probability distributions and the courage to say no when the boss wants to impose his unrealistic schedule on us.
Part 3, "Ethics", is about our responsibility to our users, our colleagues and managers, society, and – last but not least – ourselves. By consistently writing robust and effective code, we avert harm and build trust in our work.
Like all of Uncle Bob's books, this one is highly recommended. It's easy to read and, as always, is lightened by historical background and many of the author's anecdotes (though many are repeated throughout his works).
Suitable as an audiobook? The book is not currently available as an audiobook. Should this change (other works by Uncle Bob are available as audiobooks), I would advise against it due to the numerous code examples and diagrams in Part 1 (which, after all, comprises two-thirds of the book).
The Passionate Programmer: Creating a Remarkable Career in Software Development
by Chad Fowler
This book gives software developers numerous helpful and practical tips for professional success and career development.
The author describes which technical skills you should have as a programmer, how you should develop yourself technically, but also how you should not leave your career path to chance, and instead take your personal development into your own hands, pursue your own goals and remain motivated to realize them.
In particular, he describes how you should market yourself as a programmer and gives numerous short recommendations for action.
Suitable as an audiobook? Yes, but the book is currently not available as such.
Soft Skills: The Software Developer's Life Manual
by John Sonmez
In this book, developer and blog author John Sonmez gives helpful advice on building the soft skills a developer should have, and which lead to a more satisfying life as a professional software developer.
It’s all about career development, self-marketing, learning, productivity, investment strategies, and financial security, fitness, and mental health – all from a software developer’s perspective.
For a change, if you would like to read a book for programmers without source code and diagrams, I can recommend this book.
Suitable as an audiobook? Yes, absolutely. I particularly like the fact that John Sonmez reads his books himself and repeatedly adds a few paragraphs that are not in the book.
The Complete Software Developer’s Career Guide
by John Sonmez
This book is a comprehensive guide to a successful career in software development.
It answers questions from all levels of the development career: How do I start my career? How do I get a job? In which direction can and should I specialize? How do I deal with superiors and colleagues? How do I earn a promotion? How do I develop myself?
The book is written in a simple and entertaining form, enriched with personal anecdotes, and it is enjoyable to read.
Suitable as an audiobook? Yes, absolutely. I particularly like the fact that John Sonmez reads his books himself and repeatedly adds a few paragraphs that are not in the book.
Growing Object-Oriented Software, Guided by Tests
by Steve Freeman and Nat Pryce
This book provides a practical introduction to Test-Driven Development (TDD), especially in object-oriented programming.
The authors (one of whom is the developer of jMock) explain how unit tests and mock objects lead to a clean object-oriented design with reliable and maintainable code.
In a case study, they design and implement an auction system in Java with a test-driven approach.
I particularly recommend this book to every Java programmer. Once you’ve experienced how tests lead to more elegant design and code, you’ll never want to develop without them again.
Suitable as an audiobook? No, due to numerous code examples.
Agile Software Development: Principles, Patterns, and Practices
by Robert C. Martin
In this excellent book, Robert C. Martin, also known as “Uncle Bob,” co-author of the agile manifesto, explains the core concepts of agile software development, Extreme Programming (XP), and Test-First Design (the predecessor of Test-Driven Design).
He shows how to write clean, maintainable code through agile design and the application of SOLID principles.
The author then demonstrates these principles and the application of well-known design patterns using three case studies developed in C++ and Java. I recommend that every programmer study these case studies intensively and implement them themselves.
The book is from 2002 and is available in a new edition from 2013, which I haven’t read yet.
Suitable as an audiobook? No. The book is full of source code and UML diagrams that are essential for understanding this book.
Pattern Hatching: Design Patterns Applied
by John Vlissides
This book by one of the four authors of the classic “Design Patterns” gives insights into the development process and describes the ten biggest misunderstandings about design patterns.
Frequently used design patterns are explained using practical examples – in contrast to the very academic approach in the classic. Variations of established patterns are presented, as well as two entirely new design patterns.
You don’t necessarily have to read this book, but for me, it was a very pleasant and much easier to digest read after having worked through “Design Patterns.”
Suitable as an audiobook? No, due to numerous code examples and diagrams.