Fans pick 100 books like 97 Things Every Java Programmer Should Know

Unless you are writing a greenfield app, you have legacy code around. And even if you are on a greenfield app, you are writing legacy code right now.

This book gives you techniques for working on such a codebase. It is a really good read for learning how to refactor safely so you can work with what you are inheriting. You might notice this book is 20 years old. It’s just as relevant today as when I first read it in 2004. The concepts don’t depend on the exact language syntax.

In fact, some of the examples are in a mix of Java, C#, and C++. I really appreciate the perspective on testing that I got by reading this book.

By contrast to my previous 20-year-old book recommendation, this one is brand new.

When I was learning Java, we used the (now classic) “Gang of Four” book for Patterns. For design patterns, language syntax does matter. Miro covers the Gang of Four patterns and new ones using the same categories – creational, structural, and behavioral.

Miro also adds concurrency and anti-patterns which weren’t in the original GoF. I like that he includes review questions. This is very key info to know and mastering it with a modern book is very useful. Plus Miro includes examples of that pattern in the JDK itself.

In addition to Java, you need to know about the Java ecosystem.

Each chapter covers a type of tool like version control, securing binaries, or mobile. Some chapters cover a variety of tools. I particularly liked the overview of Quarkus and Micronaut. I also liked the emphasis of tools vs a role. The analogies were great such as comparing identify/fix/deploy to an oil spill.

The book is 300 pages and easy to carry around. Despite having four authors, the book is very cohesive and reads well.

Head First books are always fun. They know how to engage your brain and have cartoons/puzzles.

I recommend this book whether you are first learning git or have used it for some time. Understanding git is a big deal so you can work efficiently. Without having to keep deleting the repository and starting over!

Robert (Uncle Bob) Martin is the recognized go-to person for books on creating quality code. This is the first in a series of books that include The Clean Coder, Clean Architecture, and a number more. His advice and guidance in Clean Code have made a significant difference in my personal coding habits and best practices. This is an indispensable book for all programmers, no matter what they are coding or how much experience they have

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.

This book changed my entire perspective on writing the UI and UX of great software. Even the revised edition is a bit old but still has many valuable lessons to teach. Platt established many of the fundamental principles of writing usable and transparent software, and his book should be read not only by designers, but perhaps especially by programmers.

Wow! This book is exactly what every programmer has always wanted to know or even felt guilty about not knowing and it’s all presented in an extremely simplified and fun way. 

This is one of those books where you get excited in the morning when you wake up because you know you are going to be able to read more in the book and you are hoping the book will never end.

It’s rare to find a big book that I enjoyed reading so much and felt so short. This book covers almost everything you ever wondered about computer science. After reading this book, I felt like I finally understood everything a programmer was supposed to know and I no longer felt that nagging feeling of being an imposter.

This book helped me set my initial approach to software development and I still periodically return to it for grounding.

An MIT project theorized that new-fangled PC software developers knew something mainframe and mini-computer makers didn’t. MIT’s research revealed something else entirely: Microsoft had uniquely effective ideas on how to build complex products in rapidly evolving competitive markets. Here is “agile” before it was put into the Manifesto in 2001, in a more complete form. Ever wonder where the idea of a team comprising functional specialists with overlapping roles, united by a common goal, came from? Or incremental feature evolution with periodic synchronization and constant testing? Early brilliance still of foundational relevance, in a coherent and engaging form.

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.