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.

Fundamental concepts for people who want to improve their code. I kind of agree this book is more for new graduates than for experienced developers, but it can serve as a reference when trying to explain or justify one of the concepts explained in the book. (for the ones you agree with at least)

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.