A Philosophy of Software Design

After reading "Clean Code" as a teenager, I always run into (experienced) people who were strongly opposed to its strict opproach. Although I heard that criticism, I never got a good explanation why that is, apart from "it's bloats the code". With taking about the depth of interfaces and how shallow interfaces add complexity, this books provides a framework to explain that point.

Designing software is about managing complexity, and this book is a great explanation of that, including red flags and guidelines to practically do it.

While I don't agree with every single point made, the book provides an useful consistent philosophy and practical advice. I recommend it to everyone who cares about the design of software.

Found some of the ideas interesting, while disagreeing strongly with others. Basically same feeling as with "Clean Code", but found this book a little less valuable.

Consider some parts (general concepts) valuable, but find some of the views very religious without much foundation besides the authors beliefs / observations from teaching classes. In my experience the code you write while at university is very different because it has a much shorter lifespan (usually a course) and is much simpler + you are not very experienced as a "developer".

If you read this book as the gospel I would say you are only getting half the value and will end up getting, in my opinion, a lot of bad advice.

But if you read it with an open mind and reflect on the concepts and advice given you'll be a better developer.

A cure for overengineering

I agree with this book so much, it was almost painful to read. It has given me the words to describe what I love and hate about software development. I see from other reviews that this book is contentious. Then this is it: This is "the hill I choose to die on," as the saying goes. I agree with Ousterhout. I may have minor quibbles here and there. But if I had to follow any software religion, it would be the one taught in this book. There, I've said it.

I really enjoyed reading this book, especially if you've read [b:Clean Code: A Handbook of Agile Software Craftsmanship|3735293|Clean Code A Handbook of Agile Software Craftsmanship|Robert C. Martin|https://i.gr-assets.com/images/S/compressed.photo.goodreads.com/books/1436202607l/3735293.SX50.jpg|3779106] before. This one isn't that religious, but certainly similar opinionated.



In general most of the ideas felt more reasonable, like the points about shallow and deep modules or when to split classes. Also I really like how essential code docs are for the author, because I feel the same. Normally, business code rarely includes comments at all and I usually have to make my own, to avoid re-learning blocks I've already visited.

Nice little book. It could be an eye-opening read for a CS student as it has a lot of good advice on medium and low-level code structure. It's not as useful for a professional programmer, but it could be used for reading for pleasure. It has a couple of concepts with catchy names like "define errors out of existence" and "modules should be deep" which I like because they're quite practical and rich. 90% of the value of this book is in the first half of it.

Quotes

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)

good book with some decent reminders about fighting over complex code. Worth reading multiple times.