Good software design can be taught. Thoughtful.
Design software to reduce complexity. Complexity is caused by obscurity and dependencies. A simple interface for a module is more important than simple implementation. Error handling makes a lot of complexity; design errors out of existence. Software should be easy to read rather than easy to write. The increments of software development (for sprints or additions) should be abstractions, not features. ( )

The creator of Tcl is alive and well and teaching CS somewhere. And that is part of what makes this book great - common software design failures are drawn from examples in his classroom, so he is able to explain the reasoning behind a design choice, and then explain how to do it better.

The presentation is much less formal (and shorter) than the usual software design tome, which makes it a quick read.

It's a short book and I didn't find anything I disagree with: it's all really good advice. Ousterhout takes issue with classitis (lots of shallow, simple classes that do one trivial thing) and rightly blames Java for the rise of this style. In discussing industry trends, he takes a quick shot at test-driven development, and is much more diplomatic than I would have been ("you're not writing software! you're debugging code into existence!"). Nothing is said about devops (aka Paying A Single Worker To Perform Two Jobs), though. ( )

Makes you think, but the suggestions aren't as black and white as presented and the supporting examples are awkwardly cherry-picked. ( )

Commit this to memory ( )