Apparently there's a second edition out as of last year (2021). Ousterhout has a page about it describing the difference between the two editions and a download for those (like me) who have read the first and don't necessarily want to purchase another copy that's not <i>totally</i> different. One new chapter, one reworked chapter, and two new sections comparing his philosophy against <i>Clean Code</i>.<p><a href="https://web.stanford.edu/~ouster/cgi-bin/book.php" rel="nofollow">https://web.stanford.edu/~ouster/cgi-bin/book.php</a>
One of the reasons I appreciate this book so much, even if I disagree with parts, is the author's humble approach starting with the title, with both "a" and "philosophy". Throughout the content I also felt like he invited me to disagree with him. This made me like it was more of a conversation of trade offs rather than an argument on who is right.
Great notes! I recently read Philosophy of Software Design, but decided not to take notes on it because I wanted to finish it in a reasonable time period.<p>I'm currently a few chapters into a few other books which I chose to take notes on, but it's very slow going and my desire to read those books has decreased because it feels like a slog.<p>How do you combat the desire to note every little detail (how do you decide what's important)?<p>Also, do you take notes directly in a text editor, or do you take handwritten notes and then transcribe them later?
Not really about your note summaray but neat. I really want to make a digital garden like yours with notes and all. I read plenty of books and articles but I'm helpless when to documenting my findings.
>Programmers aren’t bound by practical limitations such as laws of physics, they are bound by their limited ability to understand the systems they create.<p>First line is already wrong. I mean I get the meaning but this is not technically true. Computing is bounded by the laws of physics. We have bottlenecks and limitations everywhere this is entirely due to physics.<p>It influences even the style of programming. There is much more parallelism in programming today due very much to physical limitations in raw speed.
I like the book a lot, however one flaw it has is that it provides too few concrete examples to illustrate what it is talking about, and thus often remains in the abstract. You basically already have to have the experience to recognize and remember the situations it’s talking about, and then nod along when your experience matches the author’s.
I'm getting delicious hints of Brooks, Gall, Deming, and Meadows in
this mix. Just reading through the TOC it feels like he's building the
premises for a knock-down argument against code mono-cultures built by
giant teams and delivered JIT on the meanest budget by corrupt
monopolies. But then of course he is.<p>As Ian Sommerville more or less said it the other day, we've got the
philosophies, the textbooks, the smart people, the pragmatism, and the
<i>need</i>, so why don't we get to build the quality of software we know
in our hearts we can make and deserve? Is what we call
"infrastructure" today a stagnation by which Capitalism ultimately
eats its own means of innovation?
It is quite extraordinary that such a treatise would not have an entire section on "What is a User?", and really very weird to me that the primacy of the user over the developer, in terms of making the thing useful, is ignored.
The table of Contents seemed interesting and I was getting ready to buy the book until I discovered - the author has reserved between 1/3 and 1/4 of the book for chapters about writing comments.