100 books like A Philosophy of Software Design

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.

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.

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

I recall reading through the authors’ lessons on software testing at about the same time I dived into more agile topics. Lessons Learned in Software Testing helped me keep the connection towards more traditional contexts – more so since I was still working in a more traditional context.

With their more than 100 lessons some of them applied to me, others did not. I am sure, other readers will find the same in their context.

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.

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.

Exploring requirements is more about communication than computing. Requirements elicitation often involves discussions between business analysts and user representatives or other project stakeholders in either one-on-one discussions or group workshops. Requirements by Collaboration presents a wealth of practical tools and techniques for planning and leading requirements development workshops. It’s packed full of useful tips, checklists, questions to ask, and activities to perform to make workshops effective and successful.

I especially like Gottesdiener’s “collaboration patterns,” eight techniques that a workshop facilitator can employ to help the group achieve its objectives. The pattern called Decide How to Decide is the first one that any group of collaborators should use: exactly how will we make decisions? If you expect to lead, or even participate in, requirements workshops, read this book first.

My journey in the world of software development has been arduous and challenging.

One of the common struggles we all face is the overwhelming number of solutions available, making it impossible to fully grasp everything at a deep level.

Just when I thought I had mastered an approach and felt competent in it, a new shiny approach would emerge, demanding my immediate attention. It often felt like a never-ending race to keep up with the ever-evolving field.

This constant pursuit of staying relevant as a software engineer can be frustrating, as it feels like we are always lagging behind the rapidly advancing world. I discovered that knowledge of specific technologies, frameworks, or libraries does not easily transfer across different technology stacks. They are too specific and lack universality. It was then that I turned my focus to more general principles of software engineering.

I realized that there are fundamental engineering… show more.