100 books like 97 Things Every Software Architect Should Know

It is my belief that half of being an effective software architect is mastering people skills.

However soft they are, these skills are the hardest to master. This book focuses on the communication and soft skills necessary to become an effective architect, and it does it superbly. The author’s elevator metaphor is perfect in that it emphasizes the fact that communication must exist on all levels within the organization, and the skills needed at each level differ.

I personally found this book very useful in honing my communication skills as a software architect.

This book was very influential in my career as a software architect because it was the first “technical” book I read that finally focused on the people and leadership skills of being an architect.

It was also the first book I read that made me start to think more about the intersection of agile and architecture, something they also devote an entire chapter to. While a bit outdated in today’s world, the authors hit the nail on the head with the still-relevant chapters on thought leadership, agility, and software architecture modeling.   

Although first published in 2004, this book continues to be my primary reference for anything related to messaging, event processing, and integration architecture.

The patterns described in this book are still highly relevant today, and are explained in a clear and concise manner that makes each one easy to understand and implement. Because you will encounter these patterns everywhere, this timeless book is a must-read book to better recognize and understand these patterns. 

Why should you spend so much time working on the software architecture of a system? Does it really matter?

This book made me realize that not all systems need the same effort of software architecture to make them successful. If you’re building a doghouse, very little planning is needed—all you need is some wood, nails, a hammer, and a saw. If you are building a skyscraper, you need a significant amount of planning and architecture, or the building will collapse.

In this book the author also talks about risk-based architecture—determining how much architecture is needed based on risk, a perspective I found very helpful in my career as an architect. 

This book provides a brief introduction to the concept of algorithms before discussing the limitations of computation. Specifically, Harel explains undecidable problems (that is, problems for which no algorithm exists) and infeasible problems (that is, problems for which only algorithms are known that have an exponential runtime). I like this book (and its splendid title) because of its focus on the limitations of computation. Harel does a marvelous job in explaining two difficult topics about computation. The understanding of any scientific discipline requires the understanding of its limits, and the limits of computation are as significant as they are surprising.

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.

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.

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.

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.

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.