![A Philosophy of Software Design](https://assets.literal.club/4/ckpq462yb3348911givswrmpsec.jpg?size=600)
A Philosophy of Software Design
Reviews
![Photo of Natalie](https://assets.literal.club/user/fallback-avatars/avatar_10.jpg?size=100)
The book I wish I had read when first began my career in software engineering. Ousterhout makes a compelling, logical case for addressing complexity in software with simple designs augmented with clearly communicated documentation, rather than prioritizing getting something working as fast as possible. A philosophy that may seem like common sense, but an important one that should be regularly reviewed by any dev, no matter what stage in their career. Linus Torvalds, on the beauty of programming: "It’s still hard to explain what can be so fascinating about beating your head against the wall for three days, not knowing how to solve something the better way, the beautiful way. But once you find that way, it’s the greatest feeling in the world."
![Photo of Suat Karakusoglu](https://assets.literal.club/user/avatar/claz7dnxn01z40i4khvrv49xd.jpg?size=100)
John has a unique perspective as both a practitioner and academician, which allows him to understand both practical and theoretical aspects of software development. This book explores interesting approaches to system design and emphasizes the importance of considering the overall health of the system, rather than just focusing on individual parts.
The book provides insights into why complexity tends to arise in software projects, but also offers practical recommendations that can change your mindset. For example, it suggests writing documentation before implementing any code, which helps in understanding the system’s abstraction better.
Thanks John,
![Photo of Mustafa Hussain](https://assets.literal.club/user/avatar/clkawybxp01a70iy98xdshv83.jpg?size=100)
I learned so many things reading this book; as I had many concepts that I have taken for granted this book reminded me to rethink about them
![Photo of Nick Gracilla](https://assets.literal.club/user/fallback-avatars/avatar_06.jpg?size=100)
This book has the makings of a classic in the field. It is a concise read. Ousterhaut asks: how can a problem be solved, with the simplest possible structure? The reading itself embodies principles of quality software design: clean, simple, obvious, with clear interfaces (in the form of problem statements and recapped conclusions). The fundamental challenge of software design is managing complexity; chapters on information leakage, poor naming practices, and unnecessary complexity with error handling are standouts. I found the discussion on an investment mindset (towards good design principles) vs tactical programming mindset (potentially driven by ‘bad’ agile or TDD) particularly thoughtful. Highly recommended, for developers.
![Photo of Julien Sobczak](https://assets.literal.club/user/avatar/clfzbngpt007f0j046lzhc1b2.jpg?size=100)
Much more insightful than the classic Clean Code. If Clean Code is about the obvious, A Philosophy of Software Design is about the subtle. This short book goes deeper and is more insightful than its predecessor. Writing clean code is great, but having a clean design is greater, and I would like more developers to read this book instead of the popular one written by Bob Martin. For many years, the author questioned if software design can be taught, and if design skill is what separates great programmers from average ones. The result was a new course at Stanford, and after three iterations, this book emerged. A Philosophy of Software Design is clearly not the definitive book on the subject. Only a few real-world projects, mostly written in OO languages, are used to illustrate the principles, and there is so much more to cover about good software design. But as an introduction on the subject, the book is excellent, especially for students. I found many references to this book by researching about the perils of clean code. A function is often more maintainable when the number of lines of code is small but sometimes, a longer function is preferable. A class is often more maintainable when it has a single responsibility but sometimes, making the common case as simple as possible is preferable. The book is filled with many examples like these. The discussions about some principles like "Design it twice" or "General-purpose modules are deeper" are invaluable. If you want to write clean code, you have to think, and this book will help you ask a lot of questions. If you read the reviews of any book about code design, you will have a lot of divergent opinions. This book is no exception. The best option is thus to read not just one book, but a lot. Make sure to include this one in your reading list.
![Photo of Thibault ML](https://assets.literal.club/user/avatar/cl1xfiofa000j0hxu09jr5er9.jpeg?size=100)
John's book is an incredible piece that all developers, junior or senior, should try to read. John has obviously been bit by many design decisions over the years, and was able to come up with different suggestions and advice that help write good quality software that has as few bugs as possible and that remains maintainable over time. For years now I had been struggling to explain in code reviews or design sessions the reasons why I gave certain recommendations. While I have learned over time to explain my decisions and design suggestions through what they help prevent/avoid or how they enable other developers, too many times still, all I had was an inkling, a feeling, an intuition. Instead, John's book clearly lay out all those things I have learned the hard way, and explains them with ease and simple examples. This is the very first programming book where I agree with almost everything that is written. I am looking forward to share this book with colleagues.
![Photo of Nathan](https://assets.literal.club/user/avatar/cm5uck0gp01yp0i334jubeoom.jpg?size=100)
![Photo of Carlos Becker](https://assets.literal.club/user/avatar/cl6qkh2l7000c0hyl4qdg0wpm.jpeg?size=100)
![Photo of always online](https://assets.literal.club/user/avatar/clbvipxt702bb0i2ydfc17mt2.jpg?size=100)
![Photo of Eduardo Sorribas](https://assets.literal.club/user/avatar/ckqhr8ko000010otu13mqdwbg.jpeg?size=100)
![Photo of Christian Bager Bach Houmann](https://assets.literal.club/user/avatar/clyun87cc00120i36htvmd1p0.jpg?size=100)
![Photo of Simon Gagnon](https://assets.literal.club/user/avatar/clvts93zl013s0i3661tpcdsr.jpg?size=100)
![Photo of Taylor Murphy](https://assets.literal.club/user/fallback-avatars/avatar_08.jpg?size=100)
![Photo of Levi B](https://assets.literal.club/user/fallback-avatars/avatar_21.jpg?size=100)
![Photo of Ika](https://assets.literal.club/user/avatar/cltk7cmal00ch0i2x1gu0atxd.jpg?size=100)
![Photo of Nik R](https://assets.literal.club/user/avatar/clotak9bw00js0izzdd84djoc.jpg?size=100)
![Photo of Sapan Parikh](https://assets.literal.club/user/avatar/cldg931x703uu0i2yhhrs2gxt.jpg?size=100)
![Photo of Shivam Shekhar](https://assets.literal.club/user/fallback-avatars/avatar_17.jpg?size=100)
![Photo of Jannis M](https://assets.literal.club/user/avatar/cliu46nhg013t0iwocgqxcpoz.jpg?size=100)
![Photo of Anwar](https://assets.literal.club/user/avatar/clh0tjqq400j10iwog22t5tya.jpg?size=100)
![Photo of Cheah Chu Yeow](https://assets.literal.club/user/avatar/cle18ra6g04hc0i4k44nx9o0w.jpg?size=100)
![Photo of Dean Sas](https://assets.literal.club/user/avatar/clbtwwf3602b70i4k82kr0c25.jpg?size=100)
![Photo of brendan sudol](https://assets.literal.club/user/fallback-avatars/avatar_09.jpg?size=100)
![Photo of mercy](https://assets.literal.club/user/avatar/cl5znhp8v001d0ivlgt9y887w.jpeg?size=100)
Highlights
![Photo of Davood Ghanbarpour](https://assets.literal.club/user/avatar/cljwpzk5v01hg0iy04tln75fb.jpg?size=100)
Your job as a developer is not to create code that you can work with easily, but to create code that others can work with easily
Responsibility of a developer