Name: A Philosophy of Software Design
ISBN: 9781732102200

A Philosophy of Software Design

"This book addresses the topic of software design: how to decompose complex software systems into modules (such as classes and methods) that can be implemented relatively independently. The book first introduces the fundamental problem in software design, which is managing complexity. It then discusses philosophical issues about how to approach the software design process, and it presents a collection of design principles to apply during software design. The book also introduces a set of red flags that identify design problems. You can apply the ideas in this book to minimize the complexity of large software systems, so that you can write software more quickly and cheaply."

What Hacker News says

jjiceOct 2026

I find that LLMs can write poorly structured code if not given a good foundation to do so. The existing code in a repo is what the LLM will see and generally output similar code to.

Given that, I'd recommend the mainstays on good general software design. One of my favorites is "A Philosophy of Software Design" by John Ousterhout. Good general design practices.

Other than that, I think a lot of books generally stay relevant. If it's topic specific, it'll give you a good background on understanding of that topic so you can make sure you or an agent are making sound decisions. Architecture of course is more valuable than ever.

thread

so-cal-schemerSep 2026

I'm sad he's retired.

Here's another plug for his book:

A Philosophy of Software Design/2e

https://www.amazon.com/dp/173210221X

thread

ankkalinnaSep 2026

I've been re-reading 1Q84 by Murakami. It left a very light and magical impression on me in high school, but I couldn't remember much at all of it anymore so decided to pick it up again and dust it off.

I'm also trying to transition into software development and have been watching John Ousterhout's talks and just yesterday started reading "A Philosophy of Software Design" - enjoying it so far.

thread

wuschelAug 2026

Books that come into my mind that might be useful to you:

A Philosophy of Software Design — John Ousterhout

Designing Data-Intensive Applications — Martin Kleppmann

Domain-Driven Design — Eric Evans

There might be some courses as well, but I never looked into them.

This also works quite well:

Write down the problem. Think real hard. Write down the solution. (Thank you, Feynman).

thread

cowboylowrezAug 2026

These artsy fartsy takes on a subject that would be better studied as a science are fun but are they useful? I am not saying there is no such thing as taste and neither will I attempt to define taste except to say "tasteless" is probably the opposite. "Judgement" seems more valuable as some have mentioned, maybe judgement and taste together identify something we want?

Still, I like better when we actually do try to name what we're talking about. We've probably all read the motorcycle guys take on quality and things like that right? I guess the theme some are going with is that quality can't be objectively quantified and to define it is futile but I've never liked that take. If we think LLM generated code is low quality then it certainly makes sense to start our attempts to define or at least describe what makes the quality needle move, because language is how we encode lots of information and information is what feeds LLMs.

People also like to rag on uncle Bobs takes, clean code, etc but I like how at least he tried. I've been a fan of his for awhile but I'm not big on objects so don't care about his pushes on that sort of thing. The best take that offered hints that I would call quality is "A Philosophy of Software Design" by John Ousterhout, there is plenty of stuff in this short little book that was very satisfying to me, like for instance where Bob wants short/small functions, Mr Ousterhout was much more flexible on this, like for instance maybe some functions can be bigger if the need arises, things like that.

thread

localhostingerJul 2026

HTMX is great for a lot of things, but if you're working in a team, and your colleagues are not on board, it's tough. Lots of "this is not a serious technology" kind of arguments. All kinds of bugs simply initially blamed on the choice of using HTMX. Even if proven wrong afterwards, the damage is already done. And this was in the most excellent team I have worked in so far.

I'm happy that I got to experience this and I learned from it. Gotta choose your battles or something.

As for Go's html/template: I think it has one of the weirdest / most unnatural interfaces. I recently reread "A Philosophy of Software Design" and one of its key points is to keep interfaces simple and push complexity downwards, making it easier for others to use. Now why do I have to care about "cloning templates" every time I render some html template? Love the Go stdlib, but this thing feels unnecessary complex to me.

thread