This is my “master list” on literature which I believe to be relevant to developers. Rather than writing a new blog post for every book I read, I will instead update this post right here. Do you think there’s a book I should read? Feel free to send the tip my way in the comments!
Some books in this list will have an emoji attached to it. The meaning of the various emojis are as follows: ⭐ -> Books I believe that all professional developers should read. 👍 -> Books I think are good, and are worth reading. You may want to avoid reading books without an emoji rating.
“General purpose books” are those books which don’t focus on a specific language or technology. Instead, they explore the various aspects of being a developer or the processes we use to craft software. These books can give value to any developer writing in any programming language. View them as “the self-help books for developers” without the negative associations.
The “clean series” is a series of books written by Robert C. Martin. His books are generally regarded as popular and informative. I think all of them is a great read and I believe they have made me into a better developer.
NOTE
Robert C. Martin is a character which many people have strong feelings over, and he has split multiple communities. I think that many of his books are a bit on the extreme side with some unobtainable goals and ideological thinking, but also believe that we should attempt to pursue such goals nonetheless. Firefighters won't be able to stop the phenomena that are house fires, but that is their goal. Many tips in these books are useful, but there are parts which doesn't work with modern enterprise development. One cannot live up to the standards which his books offer, and I have a hard time finding a company which does. While presented as gospel, one should not read his books as such. One should read the books as opinion pieces and make up your mind. There are plenty of things in these books which I find questionable or unachievable if followed as rules set in stone. I do consider his work to be well worth reading, but they have sparked heated debates on multiple occasions.
Clean code is one of the books which can be considered classic literature in our profession. It is all about how to write useful and maintainable code while keeping up with best practices. While Robert C. Martin has hijacked the term "clean code" I think he has done a lot of great with it. I agree with his way of thinking, though at times, I feel that the book paints a picture of an idealistic world. That said, I write pretty idealistically on my blog as well, which means that nothing can be applied to every situation perfectly every time, but that doesn't mean that we shouldn't attempt to reach a new golden standard. The book does show its age by now, but I think if one looks at the lessons provided in this book, then it can still be an essential read.
Clean Code is a well written and excellent book about writing software, and I think it is a book all developers should read no matter their feelings towards agile, TDD or any other practices.
This book mostly covers what it means to be a professional programmer. It spells out how we should act, what our responsibilities are and what expectations the rest of the world should have of us (as well as expectations we should have for ourselves). The book attempts to set a line between what is and what is not professional. It tries to get away from the idea that developers are just a bunch of rowdy kids doing their own thing, and which the business has to rely on and instead views developers as professionals and the burden that comes with “professionalism”. I think this book is fundamental and more people should read it.
Another excellent book, but now we have taken a step back. This book covers the general architecture of our systems, and the traits good architectures have. It discusses disciplines to create architecture which is easy to change afterwards later, or how we think about dependencies between our systems. Another big thing which this book hits on is what can be considered a detail and what cannot.
Over the years, the term "agile" has sort of lost its meaning. Big corporations have adopted parts of it and taken agile as "going fast", which is not the correct thing. Robert C. Martin seems to have gotten the memo and tries to guide agile back into its original meaning and intention while admitting that the term has become washed out. I think this book is excellent and worthy a read, even if you don't like the idea of agile or what agile has become.
Author: Frederick Brooks
This is another classic within our industry. While being a bit old, it is still an excellent read and provides insight into how we manage our projects. To these days, people in the industry are quoting this book. This book does show some age, with ideas like "the surgical team" which never really took off. Nevertheless, I think it is an essential read and something which I urge developers to read. (and managers if they're brave enough).
Author: Eric S. Raymond
If you care about open source as a movement and the ideology they hold, then this is an excellent read. The book talks about when open source is appropriate, and when it isn't. Various ways of doing a sustainable business while giving away the source code and so forth. A good and worthy read.
Author: David Thomas, Andrew Hunt
Another fantastic book about being a professional developer, writing industry-grade code and best practices. It is considered a classic within the industry for good reasons. This book covers many aspects of software engineering and summing them up here won't do it justice. I'd say that no matter how experienced a developer you are or what kind of technologies you work with this book will still give you something and be worth a read.
Author: Erich Gamma, Richard Helm, Ralph Johnson, Jon Vlissides
One of the promises of object-oriented programming was code sharing. While OOP hasn't lived up to its initial promise, it has created a set with patterns. Being aware of these patterns can help us make better architectural decisions, as well as being able to name something in a way that makes sense. The book itself is all about these patterns and can be seen as an encyclopedia on the subject. The book does show its age, but the practices it represents are still valid to this day. Being able to put something into the correct terms can be highly valuable, and I think this book does an excellent job of that, as well as being a reference one can look at when wondering how to reason about a specific architectural decision.
Author: Roy Osherove
To nobody's surprise, this is the book when it comes to unit testing. This is a very "from zero to hero" kind of book related to unit testing. How to write them, best practices, various frameworks and the difference between them and so forth. It even includes a chapter about how to introduce unit testing into a company which has historically not had automated testing. One of my favourite parts is the chapter which discusses how to test legacy code (or code that wasn't made with testing in mind). The book does contain a bunch of C# code, but the concepts are general to most languages out there, and I believe it is an excellent book for both beginners and seasoned developers.
Author: John Z. Sonmez
I'll rip off the bandage: I dislike this book. Don't get me wrong, there is a lot of good stuff in the book, but the good parts are said better elsewhere. Other parts read like an average self-help book. The good parts of the book are better covered in other books such as clean code, clean coder or pragmatic programmer. The communication part of the book is covered better in "How to win friends & influence people".
Also, I'm not too fond of the general attitude on display throughout the book. I got the vibe that this book is so focused on forwarding ones' career rather than making you into a good developer. The book talks about creating your brand and marketing yourself, either through blogs, public speaking or internally at the company. Neither of which is wrong (after all I'm writing like the wind on this blog), but I also think that the importance is not conducive to being a good developer in its own right. Soft skills seem more worried about furthering one's career than it is concerned about making you into a professional and good developer.
On other topics like burnout, the author suggests that "burning out" is only just "hitting a wall" which one can tear down given enough willpower, which I find misleading at best. The whole topic of burning out takes up a total of 5 pages. These five pages, according to the author, solves the problem of burnout. Mental health is not something ever brought up and isn't a part of the issue of burning out (according to this book. I'm afraid I have to disagree though).
The book also covers weird subjects such as finances and real estate investing or has a whole chapter on fitness. I don't think any of these topics inherently offensive or anything, but it does make the book less cohesive to me.
Whatever my opinions might be, the book is generally regarded as a good book, and it has forewords written by well-known developers such as Robert C. Martin and Scott Hanselman. It is not a bad book, but I do consider it to be a jack-of-all-trades, master of none kind of situation. All the topics are, in my opinion, covered better elsewhere, but as one book which tries to bring it all together, I guess it does an alright job.
Author: Tom DeMarco, Timothy Lister
This is the one book I wish managers read, or pretty much everyone which has any leadership role within a company which makes software. Don't get me wrong, for developers, this is an excellent read, but it's in management the lessons of this book will shine. If you ever find yourself managing a team, project or organization - read this book.
Author: Sandro Mancuso
The Software Craftsman is one of those books which is more about being a developer rather than development itself. The book is mostly concerned with how we work, practices that we apply and how to be professional. This book won’t directly make you a better developer, but it will make you consider your profession and where your career is heading.
I do have some disagreements with this book though. Most notably, the authors claim that people who want a 9-5 job should find a different profession. I don't think alienating developers who don't live and breath code is very productive, and to the author's credit, he does seem to try to instil some pride and passion into such developers. Dedication to a craft is individual. Some make it a way of life, other's do the job and get on with their life. The former will become better and be more valuable as a developer, but in the end, it comes down to what people are content with. Note that I am not saying that poorly developed solutions are acceptable.
The Software Craftsman is a good book, and I'd wholeheartedly recommend it. This is a book which wants you to analyze your career, your values and goals. It wants you to take control over your career and steer it in the right direction. The book wants you to be the catalyst for change within your company to make better software. It wants you to be a software craftsman. If that sounds like something you'd like, then you might want to read this book.
Author: Micheal C. Feathers
I went into this book hoping that this would be a recipe for how to "un-legacy" legacy code unless one considers the author's definition of legacy code: "Legacy code is code that has no tests". My initial expectation was wrong, as this book squarely is about how to make safe changes in a legacy system. The book isn't about how to evolve an old system into something which holds modern standards, or how to avoid the rewrite cycle at all. This book is about writing tests for code that is not very testable.
The author of this book rightly assumes that to make safe changes, we have to have unit tests which verify our changes. I agree with this, and 95% of this book is concerned with how we get untested code under test. It has tips and tricks on how to separate dependencies so that we can write mocks and fakes to get what we want under test. The book also contains some tips on how we can refactor safely, but it is all in the name of being able to write tests.
When I read the book, I hoped for a little more, like how to identify where facelifts are required, how to convince management that rewrites are necessary and how to argue for such a rewrite. I would also like to see tips for how to bring a borked legacy system into the modern world without having to start a greenfield project. There's a lot of things I would like to see from a book about legacy code, however that is not this book. This book is about making safe changes to the code, nothing more. Many of the practices will even make the code more confusing, and the author admits as much. While my feelings are conflicted, I must admit that they are conflicted because I thought the book was something it isn't. If we take the book for what it is, then it is excellent, and it does a great job, have the right expectations while reading it.
Author: Dustin Boswell, Trevor Foucher
This is one of those books I've had that just showed up in my kindle library and I'm not entirely sure where it came from. Most likely, it came with a humble bundle, and I just forgot about it. Either way, when randomly browsing my library, I went over this and thought "Hey, that is a title which promises a lot", and to a certain extent the book lived up to that name.
This book says that better code is readable code. I'm not ready to make better and readable synonyms. After all, perfectly readable code can not work, either from a performance or functional point of view. Therefore readability cannot be the only requirement for what can be considered "better". I do understand what the book is going for, and I agree that readability is a significant factor that is often not considered enough when writing code.
The tl;dr is that the suggestions from this book make sense. I was delighted to see how the book talks about test naming and two whole chapters dedicated to naming functions and variables! What excites me less is the two chapters regarding comments. There are a few things in the book which I would hesitate to recommend, but luckily most of them can be considered minor issues.
The thing that I'm afraid I have to disagree with maybe the recommendation that we should use todo comments. I am clearly in the "TODO is harmful" camp, but only in the sense that TODO comments in the main branch are harmful. TODO comments to keep track of some work while developing is perfectly fine, but I don't consider merging TODOs as appropriate. If we can wait, but eventually should implement something it belongs in a Github issue, Jira task or whatever ticket system that is used, not in the source code. The book even goes out of its way to say that "better code" does have todo comments which document its flaws, which I cannot agree with.
Generally, this is a decent book. Most of what it says is sensible, and it has well-chosen examples which it demonstrates its points on. This is a good book for beginners as it will open their eyes for the importance of code readability, not just working functionality. Senior developers which already nerd about readability might want to skip this one, as it probably will repeat what you already know.
Author: Gene Kim, Kevin Behr, George Spafford
"The Phoenix Project" is without a doubt one of the best books I've read on software development, or at least when looking at software development in an organization where software development is just another part of a larger company. The Phoenix Project is not strictly about software development, though, but it is very much about broken IT and how one can bridge IT and business.
This is a fantastic book for managers, tech leads, team leads, CTOs and anyone else who might have to make IT decisions. A complete must-read in my honest and humble opinion.
Throughout the "The Phoenix Project" I recognized so many terrible characteristics of a broken IT department. The book made an excellent approach to what was wrong, why it was wrong and how to tackle issues. I've worked on projects described in the book, though without the same influence as the main character (grumble grumble).
"The Phoenix Project" is an essential book for the industry. Just as important as the classics "The Pragmatic Programmer" and "clean code", and it deserves all the praise it can get. What excites me, even more, is that the book has been followed up with a more developer-focused book called "The Unicorn Project", which to no ones surprise I had to have as well.
Author: Gene Kim
While the “Pheonix Project” tells its story from the higher level of IT leadership and management, “The Unicorn Project” is much more focused on software development. The story is still within the same company as the previous book, and if you’ve read “The Pheonix Project”, you might imagine that the developer practices aren’t up to snuff either.
It is essential to talk about what this book is and what it isn’t. This book is specifically about how to enable developers to be effective. I.e. shorten feedback loops, make changes safely, enable developers to be responsible for their changes and introduce a healthy software engineering culture.
When I started reading this book, I thought it would talk much more about code and architecture, and while the book touches on these subjects, it isn’t really about such things. The book is much more concerned with the human and organization of developers.
The conversation of “The Pheonix Project” was wrapped around “The Three Ways”, and “The Unicorn Project” does the same, but with “The Five ideals”:
I’m not going to detail what each of these ideals means, but I think they introduce a good way of thinking about software development and where many companies go wrong.
My initial assumption was that this book would be for developers, but I was wrong. This book is for everyone with anything to do with software development, be it a developer, their manager or the CTO. There are some concepts which only developers will understand, but the overall lessons are general.
These books are about specific technologies or lean heavily towards a particular language or framework. Typical books of this category tend to showcase how to use a technology or language, like "C++ in a nutshell".
Author: Josh Long, Kenny Bastani
The title says it all. It is all about creating cloud systems using Spring Boot, Spring Cloud and Cloud Foundry. If you're working within the spring ecosystem, this is an excellent read either way. Sometimes it isn't easy to figure out what exists, which this book covers. It is code-heavy at times, but it is also a step-by-step guide on how to make & deploy spring boot applications using cloud foundry. It is a well written and good read.
Author: Ken Kousen
While this is a pretty light book, it is also pretty concise and covers a lot of aspects of Kotlin. When I started reading this book, my team was discussing how to combine Spring and Kotlin safely, and as a positive surprise, this book covers parts of this as well. The book is easy to follow and well written.
These are the books which aren't directly about being a software developer, nor do they have anything to do with code. A developer may still find a lot of value reading them
Author: Gojko Adsic
A book all about various bugs and how they have affected people and the world. Stories about systems designed to read license plates crashing because someone has bought the custom plate with the word "null", or a financial system going nuts because of forgotten test data. It is excellently written, though a bit jarring when jumping from grave topics where people were harmed to very lighthearted bugs. It is an excellent and fun read, though.
Author: Dale Carnegie
Wait, this doesn't look like a book about software development? What the heck!? Yeah, I know! This might be the best book with the worst title I've ever read. I hate the title, and I bought this book as a joke based on that title alone. I am glad I did because this is an excellent book on communication, which software development primarily consists of. I will say it made me think of how I phrase things or how my attitude affects people. It talks about how the choice of words matters. This is just an excellent book, and while it is not about software development, it still touches on subjects which are highly relevant to the non-technical part of the profession. I've dealt with a bunch of people in our industry which would gain a lot from reading this book, and I do consider it something that most people should read.
Author: Peter Seibel
This book stands out, as it is not really about being a programmer; instead, it is a book which interviews notable developers who have contributed heavily to our field. We have interviews with Ken Thompson, Donald Knuth, Petter Norvig and many more. It is just a fun read and a good insight into how some of the titans of our industry think about specific topics. It was fascinating to read how these legendary developers looked at how modern development has evolved.
This book won't make you into a better developer, but it is worth reading.
