Fans pick 100 books like A Philosophy of Software Design

When I work with students new to programming I often find they struggle with translating the toy problems in exercises to actually doing something in the real world.

I love this book and frequently recommend it to new programmers because it is centered around problems. Coding should be about making your life easier. At the beginning, the problems are small, but by the end, you’re learning about email, PDFs, and GUIs.

Sweigart has a great voice, and reading this feels like being guided by a friend rather than yet another coding textbook.

When helping software organizations be nimbler, I tend to stress two things: release more frequently and automate everything. Over the years, I’ve frequently got pushback from the database folks. Most DBAs and Data Architects are taught a very top-down approach and want all information upfront before creating a single table.

This book teaches how to apply abstraction layers that are common in programming but not as common in database design. The book showed me how to use versioned views to control the coding interface and upended my overall approach to designing databases.

Most of the code I write and use is open source. As a programmer, it is easy to think “open source means free.” I didn’t think much about it until one of the companies I worked at got acquired, and we had to audit our licenses.

The big company that bought us was very particular about which licenses were compatible with their needs. That was when I realized I needed to understand this stuff better. Rosen does a great job of teaching what is otherwise legalese in plain-spoken, easy-to-understand language. This book taught me why I choose the licenses I do rather than picking blindly.

I learned my first programming language as a kid, and Basic always felt like a beginner’s language. It wasn’t until I started writing C that I felt in control of the machine. This book is a classic and was on every C-programmer’s shelf in the 80s and 90s. It isn’t the easiest read but is remarkably comprehensive for a relatively thin volume. The fact that it has been in print for over 30 years tells you something about its staying power.

Nowadays, I tend to code in higher level languages, but every once and a while I dip down, getting closer to the bare metal, and brush this baby off. It is probably one of my most well-worn books.

If you check out Amazon’s best selling books on object-oriented design, you might see a relic from 1995 still hanging near the top: "Design Patterns". That book transformed software design. Its four authors will forever be known to my generation as the “Gang of Four".

Some of the original patterns may feel outdated today, but others remain essential. Pity that the book itself is such a tough read. Good thing that another "gang of four”, spearheaded by the excellent Kathy Sierra, gave us this lighthearted take on the original patterns.

The Design Patterns book was a densely packed truck of ideas. By comparison, Head First Design Patterns is a whimsical bumper car. It’s quirky and accessible, which some serious programmers found off-putting: “It’s a book for teenagers!“, they griped.

Yes, it’s not for everybody. But it’s fun, unassuming, and it teaches important concepts. So it makes my list.

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.

Many agile projects employ user stories as a way to represent requirements rather than a more traditional approach combining use cases and functional requirements. I favor the latter approach for several reasons. Nonetheless, user stories are well established in the agile development world, and if you wish to learn about them, there’s no better author to read than Mike Cohn. Cohn describes how to craft user stories well and how they fit into the agile development process.

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 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.

Many of the most significant principles of effective software development are timeless. They’re independent of the development life cycle or model, programming language, application type, and so forth. Although this book is quite a few years old now, nearly all of its contents are still valid. The 201 principles cover the full spectrum of software engineering: general principles, requirements engineering, design, coding, testing, management, product assurance, and evolution. The descriptions of each principle are concise, whereas my 60 lessons in Software Development Pearls go into a great deal more detail and offer many practical techniques.

There’s an unfortunate tendency among young software people to disregard knowledge from the past as irrelevant to them. That’s not correct. This book can help close significant gaps in any practicing software developer’s knowledge.