TLDR: Author recommends "A Philosophy of Software Design" over "Clean Code"

Interesting article. FWIW, although unrelated, this is by John Ousterhout, the author of "A philosophy of software design"

[1] https://hn.algolia.com/?q=a+philosophy+of+software+design

Second A Philosophy of Software Design it's a very good book.

I always consider if a bug is a result of the wrong level of abstraction first before fixing it.

In "A Philosophy of Software Design" Ousterhout talks about the difference between tactical and strategic programming (great book mostly because it codifies a lot of what I think is the "One True Way" so I'm biased) and it's really easy to bang out a fix for variant 98 of the bug vs rethinking it so variants 0 through 97 which haven't been reported yet but exist can't happen.

Excellent observations. The essay illustrates what it is advocating by the generous clarity, simplicity, and accessibility with which it is written.

John Osterhout wrote what may be the best elaboration of this perspective in his wonderful book "A Philosophy of Software Design."

A couple of related thoughts from an old grizzled programmer (moi ;-), gregfjohnson.com):

Rule number one: All code must follow the Porthole Principle. The fundamental issue in programming is that we each look out at the world through a mental "porthole" that limits our field of view. We are limited in how much we can see and understand at any one time. Therefore, systems must be structured so that they can be understood completely, at all levels, even though we are only allowed to investigate them piecemeal, through our own limited and finite cognitive windows.

Abstraction is the essential tool that allows us to create systems of arbitrary size and complexity. A beautifully designed abstraction is easy to understand and use. It is so trustworthy that you don't feel any need to worry about how it is implemented. Finally, and most importantly, it enables you to reason with rigor and precision about the correctness of the code you are writing that makes use of it.

(2020), but timeless.

If you like this post, you might also like reading the relatively short book, A Philosophy of Software Design by John Ousterhout, or the talk you'll find on YouTube by the same name, which covers roughly half the topics in the book.

The Pragmatic Programmer, Refactoring (I'm rereading it after many years with the 2018 edition, opinion not totally formed on this one), Working Effectively With Legacy Code, A Philosophy of Software Design. It's been a long time since I've read Clean Code, I don't quite get the hate from the other thread here today so I'm rereading it now. I figure it'll take me a couple days and worst case I'll agree with the criticism and stop recommending it.

In A Philosophy of Software Design the author talks at length about this and proposes that "deeper" modules (classes/methods/functions etc.) provide the most cost/benefit ratio, where the interface of a module is the cost and the functionality is the benefit.

Code doesn't magically become less complex by hacking it into pieces.

The Psychology of Computer Programming by Gerald Weinberg. Some dated language (which he calls out himself in the 25th anniversary edition), but overall very good.

A Philosophy of Software Design by John Ousterhout, short book, quick read. I'll be rereading it once I figure out which bookshelf my wife hid it on (she doesn't like my bookstack approach to "organizing" and moved many things to shelves while I wasn't paying attention).

I was underwhelmed by A Philosophy of Software Design. The first 100 pages are solid, but the last 70 didn't resonate with me at all.

In those last 70 pages, the author advocates strongly for lengthy comments which felt excessive and often unnecessary to me. Here's an example from page 124:

  // Controls cursor blinking: true means the cursor is visible,
  // false means the cursor is not displayed.
  private boolean cursorVisible = true;

Not specifically software design, but insofar related books that take the perspective of programmers with unique insights:

- Coders at Work (Seibel)

- Working in Public (Eghbal)

The first one is very entertaining. Read it a couple years ago and found it gives some valuable perspective. The second one is on my reading list, it was recommended around these boards.

Related to software design, there are many. The two that are on my recent list are:

- Software Design for Flexibility (Sussman, Hanson)

- A Philosophy of Software Design (Ousterhout)

I can't comment personally on their content yet, still have to work through those two, but I have zero doubts to learn something valuable. Certainly consider them.

"A Philosophy of Software Design" by John Ousterhout talks about the costs of introducing abstractions, with the implication that modules should be "narrow and deep".

The width is defined as the size of the interface (the cost) and the depth as the functionality that it buys you or maybe the complexity it hides (I'm recalling from memory, don't have the book at hand).

A file system that exposes the file interface (as in Unix) is given as a positive example. It has few functions and buys you, well, everything a file system offers.