Live data from Hacker News

Ask HN: Good books on philosophy of engineering?

news.ycombinator.com

121–130 of 140 posts

Re: Ask HN: Good books on philosophy of engineering?

#121

Earlier quoted context omitted.

Did you read the whole book yourself or just skim it? (asking sincerely)

i've tried few times to fight through first several pages - it gets dead boring and meaningless right from beginning

If none of the comments here ignite your interest, it might not be time then. I had books like that.

I also had books I can feel I need to read, and yet they are slogs. And then something happens, or I encounter an idea elsewhere, and it is as if something unlocks. And I am diving through the book… until I reach the next roadblock. I definitely would not force it.

Re: Ask HN: Good books on philosophy of engineering?

#122
post #42

Earlier quoted context omitted.

The core thing is exploring just exactly what is subjective and what is objective, and whether quality is subjective or objective. Pirsig came up with an answer, and then goes on to talk about excellence (arete). Thinking back, this discourse seems like it was deliberately embedded in a kind of every day, guy-next-door narrative in order to touch on lived experience of "quality". Although Pirsig didn't explore it, qu…

i donknow... wasting so much time just to get a basic idea that quality is important looks like a terrible book to me. Of course in the context of "books useful for engineers". If you just enjoy someone's couch philosophy - i can totally understand that and agree that the book may be great.

The idea isn’t about that quality is important though. It is that, even though people feel it is important, no one has been able to rationalize it or measure it. And that sometimes we act and talk as if we can.

I’m not sure why you keep denigrating it as a couch philosophy. Just curious, are you doing that because you have worked through philosophies from academia or the classics?

Re: Ask HN: Good books on philosophy of engineering?

#123
I recommend reading What Engineers Know and How They Know It by Walter Vincenti [1]. The book is directed towards mechanical and aerospace engineers, but discusses the philosophy and epistemology of engineering as a discipline via several case studies. A major topic of the book is the idea that engineering is not just "applied science" and does not necessarily need to use the scientific method (kinda summarized in the saying "it's not stupid if it works" in my opinion). The book analyzes several case studies to break apart the engineering process from the drawing board and through the production phase, and sometimes in multiple iterations back and forth even.

[1] https://en.wikipedia.org/wiki/What_Engineers_Know_and_How_Th...

Re: Ask HN: Good books on philosophy of engineering?

#126
post #52

Richard Hamming’s The Art of Doing Science and Engineering is one that’s really shaped my philosophy on CS. It pushes for the importance of reasoning from first principles, experimentation, and taking on extraordinary work. There’s also a fascinating and prescient section on AI and the limits of computers and how we think about them. Stripe Press makes a nicely bound hardcover edition of the book, too: https://press.…

I read this and I was really surprised by how dismissive he was of his peers! Like it was almost catty. Great book tho.

Re: Ask HN: Good books on philosophy of engineering?

#127
The Timeless Way of Building, by Christopher Alexander.

It’s about designing houses, and in a more general sense spaces for people. There is a powerful philosophy that he conveys in this book which applies to software engineering as well.

Some notes of caution though. The book is not an easy read. It’s also not very direct and quite philosophical. Also, don’t try to reduce it to just software patterns. There is a lot more in there about a sense of beauty, quality, and essence which people miss when they mechanically reduce the message to the patterns.

Re: Ask HN: Good books on philosophy of engineering?

#128

Earlier quoted context omitted.

Seconding this. It's an important book for all kinds of design I would also recommend "Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin. It focuses on crafting higher quality code, which is the property of it not only running well, but being easy to understand and to work on

I'm curious as to how you feel about this[1]? [1]: https://qntm.org/clean

While the criticism is valid, I think it misses the points of the book. It's worth reading both but the book definitely has helpful perspectives that eclipse what's mentioned on that webpage

Re: Ask HN: Good books on philosophy of engineering?

#129
post #109

Earlier quoted context omitted.

Most so the book is meant to be taken as a rule of thumb. I personally think simple interface hiding deep functionality is a really good one. I was looking at the langchain codebase last year after having read the book and the point was struck home. Many of the functions in Langchain are one line wrappers of other functions. I try to think of functions as atomic units of knowledge. Very short functions are a good ind…

To people who are experienced in writing out the full interface of modules, ie their assumptions and guarantees, it's quite clear that being a "deep module" in Ousterhout's sense is quite rare and often undesirable, and that Ousterhout's examples of deep modules are actually shallow. See https://www.pathsensitive.com/2018/10/book-review-philosophy... He gets a lot of other stuff right though. Love his writing on comm…

I think I might be missing something from that article, but I don't think they're in so much disagreement with Ousterhout.

Ousterhout's core argument is this: consider a module as its interface (measured, say, in # of edge cases) multiplied by its effect (measured, say, in # of features achieved). When comparing two modules, we should prefer modules with smaller interfaces and larger implementations, i.e. of two modules with equally sized interfaces, prefer the one which does more, and of two modules which do the same thing, choose the one with the simpler interface.

Narrow vs wide in this context seems to me to mainly be a point of comparison - in practice, narrow and wide don't make much sense when talking about a module on its own, because the dimensions of interface and implementation are not comparable.

However, this article seems to mainly be about comparing interface to implementation and arguing that, because interfaces can be very complex, often as complex or more as the implementation itself, then Ousterhout is wrong. Or in other words, if we convert "# of edge cases" and "# of features achieved" to a single comparable unit like "# of lines of code", then for Ousterhout's advice to hold, then the implementation must be more lines of code than the interface.

To me, that's kind of missing the point of the advice, which is less to do with the amount of code needed to implement something, and more to do with the capability of code vs its interface. Yes, lines of code can be a useful proxy for both dimensions, but the dimensions aren't meant to be directly comparable.

I might be missing something, though.

Re: Ask HN: Good books on philosophy of engineering?

#130

I can recommend a Philosophy of Software Design Paperback by John Ousterhout. I've been programming for 15 years and it closely parallels my own current beliefs about programming. He stands above the lower aspects of programming/code/modules, raising the discussion to a conceptual level, that you seem to be wanting. I think there were only 2 areas out of approximately 10 that I thought I had a few better ideas but a)…

His idea to keep interfaces small and powerful bothered me - I don’t think it expresses any truth about programming despite being a good rule of thumb. I kept feeling frustrated while reading. The lambda calculus has the best interface to functionality ratio possible but you don’t see humans using it to program. This objection led me to the conclusion that a better heuristic would be: programs should try to communica…

As one example, I think his formula for overall complexity is mostly correct: Total Complexity = Sum[ componentComplexity x timeSpentWorkingOnThatPart] However I would replace the timeSpentWorkingOnThatPart with the sum of the square roots of all separate times. i.e. Working on a component for 2 days straight versus working on it 1 hour every 2 weeks are quite different. But heh I'm sure there's other refinements and if I was writing a book I wouldn't necessarily include them. It slightly goes against the point of the book to nitpick these things as it's trying to help us think abstractly at a higher level.
Post reply on HN