The most recommended books for programmers

For many years I did not question the validity of the language I was using, focussing instead on becoming good at getting it to do what was needed. It never occurred to me that, say, the type system could be flawed, causing extra work and allowing unnecessary bugs to seep in.

But what if, instead of writing validation code, you could define your types in a way that makes it impossible to create an invalid instance? What if you could define state transitions in such a way that a state machine cannot transition into an invalid state? These are indeed some of the things the Idris language allows.

In his book Type-Driven Development with Idris, Edwin Brady takes you through both the ideas of type-driven development, and how they're enabled in Iris. Iris looks a lot like Haskell, but better. It even has a unique solution for the complex issue… show more.

When trying to become a better Java developer, there is so much to learn.

97 Things covers, well 97, of them in a series of brief essays. What’s cool is that the essays were written by different people so you get lots of points of view on what is important. Topics range from language (comments, fat jars) to the ecosystem (benchmarking, frequent releases) to the language-agnostic (definition of done and breaking down problems.)

Note that two of these are mine. The book is thin at just over 200 pieces. And since each “thing” is short, it’s easy to read on the go.

Even though this book is a bit older, I had a ton of fun doing the programming problems in this book. This book really makes you think outside the box as a programmer and try to solve various problems in different ways depending on what you are trying to optimize for.

I really learned a lot about not just solving a problem, but solving a problem for a specific set of goals. Overall it made me a better programmer and made me think more deeply about programming problems.

If you want to improve your problem-solving skills and have fun doing it, I would definitely recommend this book.

Software engineering involves several phases such as requirements gathering, design, programming, testing, and deployment.

This book explains techniques that allow you to build quality and robustness into every phase of the process. It discusses design, classes, defensive programming, collaboration, refactoring, and more.

The book uses many examples in an assortment of languages but the concepts apply to any programming language. In fact, the main themes like building error detection into every step of the process generalize to even non-programming parts of the development process.

If you’re an experienced developer, you may have discovered some of this book’s ideas elsewhere or even on your own, but you only need to pick up one or two new tidbits to make the book worthwhile.

When people think about software engineering they mostly think about programming, but that’s not where a project starts. It starts with requirements.

(Really it sometimes starts with company politics, bickering, excuses, and backstabbing, but requirements gathering is often the official start.)

A good set of requirements keeps developers pulling in the same direction; a bad one can make the team inefficient, cause endless arguments, set developers against each other, and make the project feel like Lord of the Flies. I’ve seen projects scrapped and restarted from scratch or even canceled due to poor documentation.

Every software developer should know at least a little about writing so they can produce clear requirements and documentation.

This book isn’t specifically about writing documentation (which is something of an art in itself), but it can help you learn how to make your business writing more effective. This book won’t turn you into Shakespeare,… show more.

I love writing good clean code. There is something refreshing about writing or reading code that reads more like a book than some obscure instructions to a machine. This book goes into the details of how to write “clean code” and what makes it clean.

I felt like I learned so much about writing good code from reading this book about things that you are never really taught in school or on the job as a software developer.

I found so much of the book so interesting because I could use what I was learning right away to become a better programmer.

If you want to become a better programmer and are looking for a book that will entertain you and be fun along the way, I highly recommend Clean Code.

This weighty tome delves deep into the low-level working of computer programs.

This book is a great resource for professional programmers who work close to the machine in such fields as embedded software, cybersecurity, and device drivers. Assuming a basic knowledge of the C language, Bryant and O’Hallaron, two CMU professors, teach how to read and understand compiled code, how to optimize it for better performance, and how to avoid common pitfalls.

This is a hard-core technical book, written by engineers for engineers, in a dense style that is nonetheless accessible and practical. I like the numerous applied problems, each accompanied by a worked-out solution.

I was quite late in picking up this book after it got published in 2014. Turned out that this mistake was all mine. Although the book is very opinionated, this masterpiece is filled with many nuggets of wisdom when it comes to writing highly maintainable unit tests. There are lots of code examples to be found as well. The ideal book to read after Test-Driven Development By Example and Growing Object-Oriented Software, Guided By Tests.

This book (an update to Software Tools by the same authors) codifies and instructs the principles by which the Unix / Linux toolset was designed. It emphasizes clear, robust code, and the building of tools, reusable, general purpose software components that can be hooked together to solve many kinds of programming and data management tasks. The lessons it teaches are timeless, and the current generation of programmers would be well served to try and learn them.

The original Software Tools was perhaps the single most influential software book that I ever read. It taught me how to think with the Unix mindset, how to make the best use of what the Unix system (and now Linux) offers, and how to focus on readability and maintainability in my own software.

During the early years of my career as a software developer, I regularly developed very small programs that would exercise parts of the system that I was working on back then. I realized very quickly that those small programs would save me a lot of time figuring out whether the changes that I made would actually work or not. Until at some point a colleague mentioned the concept of Test-Driven Development. I first did some experimentation, dipping a toe into the water to feel the temperature. It wasn’t until the first time I picked up this book that I jumped right in. From then moment on, it all made sense. Although this book was published back in 2002, for me it still is the book when it comes to the subject of Test-Driven Development.