I like programming books and I find them tremendously valuable. The knowledge I gained from reading books worth many years of experience, so it gives me a clear advantage over developers who don’t read.

Now, for the past two years my students and readers have been constantly asking me for programming books recommendations. To be frank, I haven’t read very many programming books (on the order of 15, probably), but I did read some outstanding ones.

Therefore, in this post, I’ll share a list of books that I read and loved. However, before we jump to the actual recommendations, I’d like to discuss the utility of programming books in general.

Books are as Relevant as Ever

Let’s start with the question of why would anyone read programming books today? After all, there is no shortage of high-quality blog posts, YouTube videos and full-blown video courses (I myself produce all these types of content). There is also StackOverflow. Aren’t books just legacy information carriers at this point, much like VHS tapes and CDs?

In my opinion, books are as relevant today as they used to be 20 years ago, or even more.

Sure, books about specific programming languages and frameworks did become kind of obsolete. It’s much simpler and faster to learn these concepts from videos, or even just by writing simple programs with the help of StackOverflow and blog posts (though I’m sure that even here many people would still prefer books). However, there is still no substitute for books when it comes to transferring coherent bodies of knowledge. Let me explain what I mean.

Books are Containers for Bodies of Knowledge

Software development is a complex and nuanced process and almost everything in software is a trade-off of some sort. There are many ways to do even the most trivial things, so, at higher levels of abstractions (which integrate together lower-level details), the space of potential solutions becomes virtually unlimited. Choosing one approach from such a huge set of options is already a big challenge all by itself. However, what makes it even more difficult is the fact that different trade-offs and decisions are often interdependent.

For example, if you decide to use Singletons, which are often the quickest way to get features out of the door, you’ll face major problems with unit testing and you’ll also risk turning your codebase into a mess in the longer term. But if you don’t use Singletons, then you need to learn how to share state between different parts of the system without making that state global and static. Therefore, even though implementing Singletons takes just a few lines of code, the general context surrounding this design (anti) pattern is much, much larger. The description of this context, and its inter-dependencies with other contexts (e.g. dependency injection), is what I call “body of knowledge”.

One of the most important aspects of a “body of knowledge” is that it must be coherent. The trade-offs and decisions within different contexts inside that “body of knowledge” must be fully compatible with one another. For example, as an educator, I can’t recommend unit testing and Singletons at the same time because they are incompatible. That would make the “body of knowledge” that I promote incoherent and problematic.

Books are the best way to express and share different bodies of knowledge. A good book basically contains a set of practices from different contexts that integrate into a higher-level, coherent approach. Therefore, you can adopt this body of knowledge without worrying about potential inconsistencies down the road. Towards this goal, books are the best information carriers.

Programming Books aren’t Religious Texts

When you don’t have much experience in programming, it’s totally fine to read a book and adopt its entire body of knowledge as is. In fact, for developers who have less than a year of experience, this might be the best strategy. However, even though good books contain coherent bodies of knowledge, no one guarantees that it’s the optimal approach for you (note the difference between “coherent” and “optimal”).

There is nothing wrong with reading a book and disagreeing with some of its premises. I mean, if you disagree with everything, then it probably wasn’t a very productive use of your time, but it’s totally fine to reject part of the practices proposed by book’s author(s). For instance, for pretty much every programming books I recommend below, I can compile a list of that book’s ideas that I don’t agree with. This doesn’t make the book wrong or bad. Furthermore, when a book prompts you to think critically about its author’s ideas, that’s a huge benefit all by itself.

In addition, no book contains the “complete” body of knowledge about software development. Therefore, there are always some blank spaces for you to fill (either from your experience, or other books and sources).

All in all, even though books are the best way to transfer coherent bodies of knowledge, don’t treat them as religious texts. Don’t live by them dogmatically. Think critically about what you read and don’t be afraid to reject part of book’s premises if you can formulate why they aren’t optimal for you.

Code Complete: A Practical Handbook of Software Construction, Second Edition

As I already said, programming books aren’t religious texts. However, if I’d need to name a book which came the closest to being “the Bible of programming” (or whatever religious text you consider the most sacred), Steve McConnell’s Code Complete 2 would be it.

The best aspects of Code Complete is the breadth of covered topics and the fact that it explains the larger scope of software development. Starting with naming of individual variables, and all the way up to architecture, technology choices and effort estimation, Code Complete contains a huge amount of useful information. The discussion of quality assurance strategies in this book is second to none and it’s a real eye-opener. For example, if code reviews aren’t part of your company’s culture yet, convince your teammates to read Code Complete. They won’t be able to ignore this practice after that.

In my opinion, you can start reading Code Complete the moment you are comfortable writing simple code. So, several months of experience will do. And there is practically no upper limit on your experience level to get a tremendous value from this book. I’ve met quite a few developers having titles like senior or architect for whom this book would be extremely useful.

Clean Code: A Handbook of Agile Software Craftsmanship

The second book on my list is Clean Code. I’m sure this won’t come as a surprise to my long-term readers and students because I quote Robert C. Martin, also known as Uncle Bob, the author of this book, left and right in my articles and courses.

Now, to be accurate, I shall point out that even though this book has Uncle Bob’s name on it, it’s actually a collaborative effort. So, a complete list of authors includes Michael Feather, Timothy Ottinger, Jeffrey Langr, Brett Schuchert, James Grenning and Kevin Dean Wampler. All of these people are prominent figures in the industry in their own right.

What I like about this book is the level of details. It doesn’t cover nearly as much ground as Code Complete and doesn’t go into the larger context, but it contains some of the most detailed explanations and examples I’ve ever seen. For example, in the attempt to demonstrate higher-level considerations, Clean Code contains pages upon pages of a source code. That’s something very unusual for printed books.

Technical content is great, but what makes Clean Code truly special is the fact that Uncle Bob is among very few authors who dares to discuss professionalism and personal responsibility. Whether you’ll agree with his point of view or not, this book will encourage you to think about what it means to be a good programmer.

Clean Code requires very little upfront knowledge, so you can start reading it once you can put a simple “hello world” together. Unfortunately, many developers see it as just that: a resource for newbies. That’s a huge misunderstanding, in my opinion. For example, even experienced developers often aren’t aware of the fundamental distinction between objects and data structures. For them, Clean Code would be very useful even if they’d read just one single chapter of this book.

Effective Java

Effective Java by Joshua Bloch is simultaneously beautifully-named and poorly-named book. How is this possible?

Well, the name Effective Java is simple and elegant, which is great. However, this name also restricts the potential audience to just Java ecosystem. That’s very unfortunate because, at its core, Effective Java is a great source of information about Object-Oriented Design in general. Sure, it caters to Java developers and contains many Java-specific discussions, but even developers who don’t know Java will learn a lot from this book.

Titles of some of Effective Java’s chapters, like “Favor Composition Over Inheritance”, became software development mantras. Countless developers proclaim them as undisputed truths, which is non-optimal (to say the least) because each of these “simple” recommendations in Effective Java is supplement by a very thorough discussion of the associated trade-offs and nuances. And, boy, in most cases there are a whole lot of nuances to learn about.

Effective Java is a bit advanced resource because it deals with the intricacies of Object-Oriented Design, so I’d say you need at least one year of hands-on experience with some OO language to feel comfortable reading this book.

Clean Architecture: A Craftsman’s Guide to Software Structure and Design

If the title Clean Architecture reminds you of something, it’s not deja vu. This is the second book from Uncle Bob, the author of previously recommended Clean Code, on my list.

Clean Architecture kind of picks up where Clean Code culminated. In this book, Uncle Bob and other authors discuss higher-level considerations concerning the structure of software projects. There is a lot of gold in Clean Architecture, but one of my favorite topics covered there is packages’ structuring. That’s one of the most important aspects in any codebase, yet I haven’t seen much detailed discussion around it in other books.

Now, you might think “why would I need to read an entire book, if I can learn clean architecture from a blog post?”. Maybe you even use “clean architecture” in your application already. Well, unfortunately, many authors who create content about “clean architecture” don’t really understand it. It looks like much of that content boils down to drawing concentric circles with arrows and using “interactors” and “gateways” (or “repositories”) in code. That might be part of “clean architecture”, but it’s far from being its complete “body of knowledge”. In addition, if you don’t understand the associated trade-offs and nuances, you’re very likely to end up over-engineering your code.

Clean Architecture is very well-written, but it’s relatively advanced book. Therefore, I’d recommend picking it up only if you already have two or more years of professional experience.

Domain-Driven Design: Tackling Complexity in the Heart of Software

I find it very challenging to explain what Eric Evans’ Domain Driven Design is about. Not because it touches upon many topics, but because I feel that anything I can say about this book won’t convey its full ingenuity. So, let me start by describing my experience while reading this book, and then I’ll try my best at summarizing its content.

Imagine opening a book, reading the very first pages, and right away getting a major “aha! moment”. Now imagine this moment turn into a continuous “aha! experience” that accompanies you for the entire duration of a book. That’s how I felt while I was reading DDD. It took my preexisting experience and intuition with software, highlighted the most challenging and painful points, gave them names and then organized the resulting concepts into a clear structure. You probably imagine a set of beautiful UML diagrams at this point, and DDD indeed contains a fair amount of these, but that’s not what I mean. So, let me attempt to describe what this book is about.

We all know that naming is important, right? Having good names for variables, methods and classes is crucial because this makes a huge difference in maintainability of your codebase. I read about naming in several books and I thought that I understand how to get this aspect right. Then I read Domain Driven Design and realized that I didn’t know anything.

Domain Driven Design can be described as a deep meditation over the concept of naming. It shows the importance of discovering meaningful names that borrow from real-world business domains and create a “ubiquitous language” which is used by both R&D staff and business domain experts. I know that the previous sentence is difficult to understand. That’s why I said that I find it challenging explaining what DDD is about. Nevertheless, it’s something of enormous importance.

This book had a tremendous impact on me professionally and I constantly use the ideas I learned there when I work with clients. Sometimes, developers even become annoyed at how much emphasis I put on naming, but, eventually, it always turns out to be very fruitful effort.

Domain Driven Design is a very advanced book. Not because it uses complex language or concepts (it doesn’t), but because it builds on real-world examples and intuition. That’s something you get only through working on real-world projects, so I’d say you need to have three or even four years of professional experience to get the most out of this amazing book.

Books Loosely Related to Programming

In the previous sections I recommended several outstanding programming books. Hopefully, you found your next read there.

However, I also read several amazing books which are kind of related to programming, but not exactly. Nonetheless, I suspect you might be interested in these books as well, so I’ll describe them below.

Software Estimation: Demystifying the Black Art

I always sucked at estimations. Whenever I had to provide timelines for my programming tasks, or for any other effort really, the resulting numbers had always been way off the real outcomes. It became especially problematic when I switched to freelancing because when you charge fixed rate and underestimate the project by a factor of 3, it’s very painful. Software Estimation: Demystifying the Black Art by Steve McConnell (the author of Code Complete, the very first book on this list), explained why I was so bad and provided practical means to improve my estimation skill.

At the very beginning of this book, the author asks you to estimate several quantities, not related to software. Then you compare your estimations to the actual numbers and get a grade. This seemingly simple exercise blew my mind because, even though the author had carefully explained that an estimate is a range and allowed me to specify whatever range I wanted, I still got my estimates wrong in the most part. For me, this demonstration of my inability to estimate even simpler quantities than effort on software projects was a revelation. The following sections in the book provided lots of useful, quantitative information and techniques that I constantly use nowadays. I still suck, but not by a factor of 3 anymore.

This is an advanced book which discusses kind of “niche” subject. It’s not a good fit for new developers, and, in general, I suspect it’s not for everyone. However, if your career success or your peace of mind depend on your estimation skill, this book can be worth its weight in gold for you.

The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography

The Code Book is a marvelous collection of stories about various applications of cryptography throughout the history. Very interesting and intriguing stories, I must say. In addition, it can serve as a gentle introduction into cryptography for developers who hadn’t had a chance to explore this topic yet.

Now, this is not an academic text, and not even a practical guide. It’s mostly a history book. Therefore, if you already know when and why to use hashes, what’s the difference between symmetric and asymmetric encryption and what SSL is, there is not much practical value in this book for you. However, even though I read this book after I had already learned all the aforementioned concepts, I still enjoyed it tremendously.

Where else could I learn about how cryptography brought down Mary, the Queen of Scots; how researchers decipher and bring back to life ancient languages; the details of Enigma’s decryption; and much, much more? As far as I can tell, The Code Book is almost unique in this context. This is truly amazing book, so if you have any interest in either cryptography or history, you should definitely read it!

Ghost in the Wires: My Adventures as the World’s Most Wanted Hacker

This book is one of these cases when the title says it all. Well, I can’t really verify whether Kevin Mitnick, the author of Ghost in the Wires, was indeed world’s most wanted hacker, but, otherwise, it’s about adventures of a hacker wanted by the FBI.

The thing about Ghost in the Wires is that it reads as a spy-action-adventure book, not as a book about infosec. It’s an outstanding writing, independently of its practical utility. You don’t even need to belong to the tech world to enjoy following Kevin’s mind-blowing adventures described in this book. At times, while reading Ghost in the Wires, I thought: “This can’t be true!”, but, as far as I know, it’s all real.

However, there are many great books out there, so why I decided to include Ghost in the Wires specifically in this list? Well, infosec field is loosely related to software world, so this book also has a practical aspect to it. However, the practical aspect of Ghost in the Wires is neither a deep dive into cryptography nor your average enterprise infosec training.

Instead, the main takeaway from Ghost in the Wires is that people are also “hackable”, and that’s often the simplest attack vector. If you ever heard the term “social engineering”, then that’s what this book is all about. I knew this term before I read Ghost in the Wires, but I couldn’t even imagine how easy it is to gain access to protected information and assets using this technique. So, if you read this book, you’ll not only enjoy an amazing adventure story, but will also learn about some exploits that might one day be used against you.

Conclusion

Alright, finally I compiled the list of my favorite programming books. Hopefully, I’ll be able to answer a question about recommended reading with just a link in the future 🙂

I’m confident that if you read any of the books mentioned above, you’ll get a tremendous value out of it. By the way, if you already experience analysis paralysis because you can’t choose which book to start with, I can totally understand that. It’s indeed a difficult choice. Maybe try to analyze your current professional pain points and then see which of my summaries sounds like a solution, or, at least, the closest thing to it.

By the way, the links in this post are affiliate links to Amazon. You can follow them to read additional readers’ reviews before you make up your mind and, if 30 people will buy their next book using one of these links, I’ll get my own next book for free 🙂

I like books and I learned a great deal from them. So, read books, folks. They’re totally worth your time!