A Philosophy of Software Design

Great book and definitely one I'd recommend, but not all chapters equally.

It starts off strong. It defines complexity for the purposes of the book and why it's problematic, and then goes on for a few chapters on how to avoid it. Separates strategic “focus on the design” coding and tactical “get it working” coding, and spends the whole book emphasizing that you want to be strategic most of the time.

The next ~8 or so chapters go about what is good design that reduces complexity. I recommend chapters 4 (modules should be deep), 6 (general-purpose modules are deeper), 7 (different layer, different abstraction), 8 (pull complexity downwards), and 10 (define errors out of existence). They have solid and concrete advice that I haven't seen elsewhere, at least not explained so clearly.

Chapters 12 and onward have some interesting stuff but I think it declines compared to the first half. Skim through them and see if anything catches your eye. Two interesting ideas I noted down are:
* From Chapter 19 (Software Trends), that in agile development we should consider the iterative unit of development the abstraction and not the feature. That is a way to combine the quick iterative approach of agile with the strategic programming approach encouraged by the book.
* From Chapter 20 (Designing for Performance), a way to approach improving performance while keeping the code clean - by focusing on what the “ideal state” would be of the critical path in terms of performance and then approach it following the rest of the advice of the book.

Overall a book I liked a lot and would probably recommend the first half of it to pretty much anyone.

Excellent book. I loved the way it is written, concise and easy to read.

I would recommend this book to anyone that takes software development seriously. I have read a few comments mentioning that it talks too much about comments, but I disagree with those and agree with the author, comments are very important and it is really hard to write clear, effective and useful comments.

I would say that a chapter on code reviews is missing, following the same line of thought that for comments, I think code reviews are not easy to do or obvious. Bad code reviews can make a project fail and I know some people will disagree but in my opinion, software design is way more than code.

An opinionated collection on how to design software focusing on its complexity.
While a lot of design principles feel close, there's little to none valuable information about them. Typically there's a vague discussion-like description of the problem with indecent backing (author's feeling, observation from a couple of student solutions), followed by “examples” that really don't provide additional value to the point.
As a recent book on design principles it missed the chance to have a proper literature analysis on the topic.