For this round of book therapy, I will be reading two books, “Experts vs. Imitators” and “Just Enough Software Architecture”.

Experts vs. Imitators#

Experts and imitators can be difficult to distinguish. Imitators may sound like experts but lack deeper understanding, struggle to explain concepts in their own words, and get frustrated when asked probing questions. True experts, on the other hand, can discuss the limits of their knowledge, admit to failures, and adapt their communication style. Additionally, popularizers who effectively communicate complex ideas are often mistaken for experts, when in reality they may not have the same depth of expertise. The key is to look for signs of genuine, earned expertise rather than just surface-level proficiency.

Comments:

  • Imitators can be as good as experts, and that it is hard to distinguish between the two.
  • The impact of imitators on online communities – they can clog up communities and devalue genuine expertise.
  • The importance of critical thinking and being able to tell the difference between bullshitters and experts.
  • The value of expertise and its limitations – some arguing that it is often overrated.

Just Enough Software Architecture: A Practical Approach to Designing Effective Software Systems#

Just Enough Software Architecture is a book that aims to teach a risk-driven approach to software architecture and design. It democratizes architecture knowledge, making it accessible to all developers, not just architects. The book focuses on the technical engineering aspects of software development, providing practical advice and models to help developers reason about medium to large-sized problems. It covers key concepts like the domain model, design model, and code model, as well as techniques for ensuring effective encapsulation and partitioning. Overall, the book seeks to build up a rich conceptual model of software architecture that can help developers see systems in a more holistic way.

Comments:

I haven’t read this book, but have read a few - “Domain-Driven Design” by Eric Evans. DDD can influence your software design skills. The concept of a shared domain language between developers and business domain experts, enabling precise and clear communication. The idea of ubiquitous language and bounded contexts is a powerful concepts from DDD. Code as Design: Three Essays by Jack W. Reeves is a concise alternative to the DDD book.

We can compare the DDD book to other books like “Clean Architecture” by Robert Martin, with varying levels of agreement. Clean Architecture in practice is bad. It requires a decent amount of upfront boilerplate code.

Another book by John Ousterhout, “A Philosophy of Software Design” is great. I get a lot out of it. It contains many of solid easy to understand technique with many examples. A quick summary of this book:

The book argues that despite more than 80 years of programming experience, there has been little conversation about how to design programs or what good programs should look like. The author highlights that while there has been discussion on software development processes and tools, and analysis of programming techniques, the core problem of software design has not been fully addressed.

The author states that the most fundamental problem in computer science is problem decomposition and that is the central design task that programmers face daily, however, it is not a central topic in university classes. We teach for loops and object-oriented programming, but not software design.

The author believes that software design skill can be taught and is what separates great programmers from average ones.

The author acknowledges that he doesn’t have all the answers about software design. He explains that his ideas about software design come from his personal experience of writing and reading code.

He has extracted common threads, both about mistakes to avoid and techniques to use, and presents them in the book.

He does not claim that this book is the final word on software design and acknowledges that there may be valuable techniques he missed and some of his suggestions may turn out to be bad ideas in the long run.

The book is an opinion piece and the author welcomes feedback on what works and what doesn’t.

He advises the readers to take the suggestions with a grain of salt and prioritize reducing complexity over any particular principle or idea.