Found in 12 comments on Hacker News
Read extensively, practice your craft & don't lose your focus.

These books will help you day-to-day with your general programming knowledge...

> Philosophy of Software Design

> The Pragmatic Programmer

> Clean Code

> Mythical Man-Month

bch · 2020-01-30 · Original thread
You’re right re: it’s early internals, and we probably both know people who still (mistakenly) complain about that. Conceptually the “everything is a string”(EIAS) model still holds though, even though it’s supported by dual-ported “objects” w native representation, and the running is often byte-compiled instead of string parsing. We’ve got early smart fans who saw the vision and possibilities like Karl Lehenbauer, Don Libes, Richard Hipp, and the current core team like Kevin Kenny, Don Porter, Donal Fellows, etc who deeply understand What Tcl Is, and strictly maintain it, even while pushing it ahead (TclObj, finally an in-core blessed object system, native database framework, Miguel Sopher’s(RIP) work on the stackless non-recursive engine (NRE) and coroutines that fell out of that work...

Back to Ousterhout though, you might dig his “Philosophy of Software Design”[0] book, or talks associated with it[1].

Lots to like in this space...



MeteorMarc · 2019-11-10 · Original thread
The book "A Philosophy of Software Design" should interest you then: It argues, among other things, that deep interfaces matter more than code complexity inside a module.
afarrell · 2019-10-21 · Original thread
The sense that the platform's interface (API, dashboard, Docs) create an interface of which I can gain a solid mental model. A "solid mental model" is knowledge which enables me to predict how the platform would my code/actions would make the platform behave, to feel confident in those predictions, and to be correct.

Why does this draw me to a platform? Because it leads me to think that I'll be able to use it to solve business problems[1] despite having non-infinite mental abilities[2]. That includes the ability to communicate about timelines with stakeholders.

What makes me think that about a platform?

- Well-written documentation, with appropriate amounts of the 4 types of docs: tutorials, model explanations, how-to guides, and references.[3]

- If applicable, docs which show how to write automated tests with the platform.

- Interfaces which do a good job of containing complexity. The information they require me to learn "pays its rent" for the space it takes up in my mind. The modules are deep enough to have solved problems that would otherwise take up my time.[4]

- An active community so that StackOverflow has a body of high-quality questions and answers.

[1] see

[2] see

[3] see

[4] see a concise book which is worth the £8 and 150 pages.

xxxpupugo · 2019-06-24 · Original thread
Highly recommended this book:

A Philosophy of Software Engineering:

This is mentioned as one of the symptoms/appearance of bad code: Shallow/Passthrough methods, which results deep call chains, adding up cognitive overload. The author in this book recommends deep module over shallow module, which tends to end up with more cohesive code.

achou · 2019-06-21 · Original thread
I think the best single observation about cognitive load is in Ousterhout's book A Philosophy of Software Design[1]. In the book he promotes the idea that classes should be "deep", such that their top-level surface API is small relative to the complexity they hide underneath.

This applies to the microservice/monolith debate as well. And it basically boils down to the observation that having lots of shallow services doesn't really reduce complexity. Each service may be simple unto itself, but the proliferation of many such services creates complexity at the next level of abstraction. Having well designed services with a simple API, but hide large amounts of complexity beneath, really reduces cognitive load for the system as a whole. And by "simple API" I think it's important to realize that this includes capturing as much of the complexity of error handling and exceptional cases as much as possible, so the user of the services has less to worry about when calling it.


TeMPOraL · 2019-04-13 · Original thread
From the link, about comments:

  Use as explanation of intent.
  Use as clarification of code.
  Use as warning of consequences.
Here's a link to a well-known recent book, half of which is pretty much about why those points are a real and frequent thing, and why code should be much more thoroughly commented than it's recommended by the usual philosophies.

ben336 · 2019-01-26 · Original thread
Philosophy Of Software Design is a recent work on the subject


Book review I wrote a while back:

fdsvnsmvas · 2018-09-10 · Original thread
Thanks everyone, the comments are much appreciated. Here's a list of books and other media resources recommended so far in the thread:

Robert C. Martin, Clean code:

Vaughn Vernon, various:

Steve McConnell, Code Complete: 2

Clean coder: videos

Hunt and Thomas, The Pragmatic Programmer:

Hitchhiker's Guide to Python:

Dustin Boswell The Art of Readable Code:

John Ousterhout, A Philosophy of Software Design: This one looks particularly interesting, thanks AlexCoventry!

Kent Beck, Test Driven Development:

Dan Bader, Python Tricks: The Book:

Ian Sommerville, Software Engineering:

Svilen Dobrev, various:

lboasso · 2018-08-30 · Original thread
Another excellent resource is "A Philosophy of Software Design" [0], from John Ousterhout (known for Tcl/Tk, Raft, RAMCloud, Log-Structured File System). Like Niklaus Wirth, he is striving for designs that fight complexities and yield simple and powerful abstractions. This book is so much better than overrated books like "Code Complete" and "Clean Code" for a fraction of the page count.


chubot · 2018-08-17 · Original thread
sitkack · 2018-07-04 · Original thread
For the Tcl internals, was this John Ousterhout's code or some other codebase? Have you read his new (ish) book on Software Design? [1]


Fresh book recommendations delivered straight to your inbox every Thursday.