There is some overlap with other books such as "Code Complete" and "Clean Architecture"; this book fits somewhere in the middle as it discusses both low-level, "tactical" aspects as well as high-level architectural issues. The overlap is confined to a few chapters in the second part of the book and, depending on your experience, some other parts might seem obvious or common sense - but there is more than enough meat in this book - at least there was for me, a programmer with around 10 years of experience.
The book contains 20 short, to-the-point chapters. The overarching theme is complexity - almost every chapter is in some way concerned with eliminating, reducing or just managing this aspect. I found particularly intriguing the author's take on "sizing" modules and designing their interface; module, in the general sense of the word - could be a class, component, etc. The current "best practice" is to design just enough to address current needs, and prefer a reduced scope. The author argues that we should favour designing a more general-purpose interface as it conceals most implementation details and reduces "leakage", therefore confining as much complexity as possible to the inside of the module itself. This approach also leads to "deeper" modules, as opposed to "shallow" ones which generally require more complex and specialized interfaces.
Designing general-purpose interfaces is more time consuming, but the author encourages us to see it as a long-term investment, and contrasts this view with the "tactical", "just-make-it-work" approach which often leads to runaway complexity. Throughout the book, the author proposes this type of approaches to design as one of the main tools for combatting technical debt and managing complexity. So much so, that there is a chapter named "Design it Twice". Rallying against technical debt is not new in itself, but I think the author does an outstanding job at getting to the crux of the matter and elaborating on solutions to mitigate it.
The author makes a convincing case for his arguments, providing examples where appropriate - and, something which most similar books don't do, also gives counter-examples of "taking it too far". There is also an interesting take on some current trends - like TDD, which the author argues against. Much like any "best practice", advice in the book should be taken with a grain of salt but if you're looking for a fresh perspective, this book delivers.