A Philosophy of Software Design, 2nd Edition Paperback – July 26, 2021

I think every person who has written a fair amount of code should read this book. Managers should buy it for their teams. It should be required reading for new team members (it doesn't long to get through - a few hours).It is NOT for beginner programmers in my mind - you will not have written enough code to understand the points being made. I'd say it's perfect for mid-level to advanced programmers. Why for advanced? Because they can quickly get throught it, and challenge some of their own design assumptions and practices. Mid-level programmers will find it a treasure.The title of the book is perfect, because it really is more philosophical and high-level. But that doesn't mean it's abstract nor boring. I find the ideas very applicable and easy to understand. The opening statements are very powerful - what is complexity, the difference kinds of complexity ("cognitive load" is an excellent concept), etc. It ends with a gem - you know your code is complex if you end up spending a lot of time fixing bugs in it. Complexity begets complexity.Don't let the critical reviews stop you from reading this book - so what, it ignores functional programming. Readers can buy books on that and contrast the desgin philosphy. Yes, it's OOP-based, but so what? It's easy to apply these ideas to non-OOP languages or concepts.Some complained about "3 chapters on comments alone". Not true - the three chapters cover different subjects, and provide excellent guidelines for commenting first (designing with your comments - kind of like writing a mini-spec, if you will), what constitutes a useful comment, and how to name variables. I found it very useful.The concept of "deep" versus "shallow" classes is very interesting, even if some of the reviews have criticized it. The author provdes a very nice clue to whether or not code should be broken out - do you have to keep flipping back and forth between the sub-task and the original function? Maybe it shouldn't have been broken out. Deep classes have simple interfaces and accomplish a lot for the caller. Shallow classes, on the other hand, require the caller to know about them, how to call them in order, etc. Good stuff.It's a short read. You'll scarcely find a book that's so short be so valuable.You can get through it in about 3-4 intense, focused sessions.

I loved the first half of the book; I created around 25 highlights in the first half of the book. This part of the book focuses on trade-offs and recommendations in software design and code structure, e.g., module depth, layers, abstraction, generality vs specificity. Many of John's views here were unique and engaging; at least, in presentation.As for the second half, it focuses on documentation, comments, code readability, maintenance, and performance. While I liked the recommendation in maintenance, it could have been folded into an earlier chapter in first part. The performance chapter and parts of "Software Trend" (e.g., TDD) were unique. As for the rest, it was a bit dragged out. This may be partly because I had read a more detailed book in the topic -- "Art of Readable Code", which I highly recommend.

A lot of what's discussed in the book is stuff I've already intuitively learned through trial and error over the years, but to have it clearly laid out in a detailed, well structured and methodical way is still very helpful for building a stronger mental model of things I've been thinking about for years. I wish this book existed when I first started my career.It's also a great resource to build alignment on system design goals in a team as well as defining a nomenclature around software design that helps clarify and facilitate discussion. While I'm sure not everyone will agree with everything discussed in the book, it still creates a great framework to be able to discuss software design and make conscientious decisions even when you decide to diverge from the advice in the book. I'm recommending this book to other developers in my company.

Very interesting book, with modern view on software development. What I really like about this book that it's up to the point without extra information. I also like John's honest opinion on different topics, which are in some cases are different from what we here on media and what we study in colleges. For instanceI also learned about:1. Tactical versus strategic approach.2. Tactical tornado programmer - prolific programmer who pumps out code far faster than others but works in a totally tactical fashion.3. The extreme of the "classes should be small" approach is a syndrome called sclassitis, which stems from the mistaken view that "classes are good, so more classes are better"4. Pass-through variables5. Splitting and joining methods. "Long methods tend to be more difficult to understand than shorter ones, so many people argue that length alone is a good justification for breaking up a method. However, length by itself is rarely a good reason for splitting up a method. In general, developers tend to break up methods too much. splitting up a method introduces additional interfaces, which add to complexity. It also separates the pieces of the original method, which makes the code harder to read if the pieces are actually related. You shouldn't break up a method unless it makes the overall system simpler.6. If it's hard to find a simple name for a variable or method that creates a clear image of the underlying object, that's a hint that the underlying object may not have a clean design.7. Comments belong in the code, not the commit log.8. If information is already documented someplace outside your program, don't repeat the documentation inside the program; just reference the external documentation.9. Don't change existing conventions. Resist the urge to "improve" on existing conventions. Having a "better idea" is not a sufficient excuse to introduce inconsistencies.10. One of the risks of agile development is that it can lead to tactical programming. Agile development tends to focus developers on features, not abstractions, and it encourages developers to put off design decisions in order to produce working software as soon as possible11. The problem with test-driver development is that it focuses attention on getting specific features working, rather than finding the best design.