100 Books Like A Philosophy of Software Design

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.

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

A common reason for microservice projects to fail is a lack of understanding of how to build resilient and fault-tolerant microservices.

This book was a game-changer for me, providing essential strategies to address these challenges. It taught me how to avoid anti-patterns like Cascading Failures and embrace patterns like Circuit Breaker and Bulkhead to manage temporary network issues and overload situations. The real-world solutions it offers were immediately applicable to my projects.

Next to Fred Brooks' The Mythical Man-Month, this is perhaps the most classic of all classic programming books.

The authors write: "Besides showing how to make effective use of the language, we have also tried where possible to illustrate useful algorithms and principles of good style and sound design."

The book is astoundingly practical as a tutorial, which is itself a testament to the Unix "pipe" model of programming: By page 13, they've introduced getchar and putchar, and by the end of Chapter 1, twenty pages later, you've implemented a host of useful utilities including cat, wc, and detab. In Chapter 5 you implement a function recognizable as the now-standard qsort; in Chapter 8 you implement malloc itself.

Now, I recommend "K&R1," not the more popular "K&R2." The first edition was issued in 1978 at a slim 225 pages; the second edition, a decade later, added conformance with ANSI… show more.

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.

“Good agile testing is good context-driven testing applied in an agile context.”

The authors of this book summarize their decades of experience in software testing in over 100 lessons they learned. Follow them along different aspects of the tester’s job, as they re-tell various stories collected over the years with some clear guidance to surviving and testing project.

These software testing industry leaders have some timely contextual advice in here – whether you work as a tester on an agile team or in a more traditional fashion.

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.