Ask HN: Most interesting, mildly impractical, well-written books on software?

Prompted by this comment, I'm reading it again. Holy cow, this is better than I remembered. So relevant too; it's hard to keep in mind that this is from before Unix.

The author was involved in numerous cognitive experiments with programmers, and also as a teacher. His group researched programming language development. So a lot of it is from that angle. The book is full of interesting anecdotes and gems of wisdom.

You're missing out on some of the best writing on any topic!

Not all Knuth's books are the same: The Art of Computer Programming (TAOCP) is his mangum opus, an ever-expanding encyclopedic knowledge fire-hose of various computer science topics. But the series of books that are simply "collected papers" makes it easy to focus on something much narrower. For impractical, you may want to start from Selected Papers on Fun and Games.

And then he has books like Surreal Numbers, which is written as a story of a couple discovering mathematical notation and deriving a whole system...

To detect errors, the programmer must have a conniving mind, one that delights in uncovering flaws where beauty and perfection were once thought to lie. Perhaps a touch of paranoia helps---the kind of thinking that automatically conjures up the worst imaginable cases.

For locating errors, however, we want a person who has the persistence of a mother-in-law and the collecting instincts of a pack rat. In one project, for instance, a bug in the operating system was known to exist for six months before it was finally tracked down by one programmer who had saved every dump taken in that period---three nine-foot stacks of paper! Late at night he could be found poring over his dumps---searching, groping, rummaging about for some slight clue that would have escaped the eye of a Sherlock Holmes. Months went by, and then, in one dump, a single bit which didn't seem quite right. Back he went through all the other dumps, until he had ferreted out two more cases, then five, then a dozen out of the hundreds. These twelve cases he arranged on a large table, first in one pattern, then another until some threads of connection became visible.

By this time, his mind was so specialized to the cases at hand that it was fruitless for him to try to explain his hypothesis to anyone else. It seemed to him that one of the data channels---when certain conditions were just right---was picking up a bit in one of the positions of its address register, thus causing a single character to be stored out of its regular sequence. Since this error usually occurred in the middle of a large data block, the stray character was usually wiped out by subsequent characters in the block, but in a few cases---the twelve---the character was found just past the end of the block. He tried to convince the engineers, but they would not listen. Programmers always say that there are machine errors. So, finally, he constructed a program that would force the channel into just the right circumstances with an increased frequency. Then, when made the error occur with more regularity, he was able to define the circumstances with enough precision to find on the schematic exactly the circuit card that must be in error. The engineers were impressed with his diligence, so they finally granted him a test of the card---and found he was right!

Such programming sleuths are not rewarded for their discoveries with the fame of a Pasteur or a Salk. Nonetheless, they are satisfied--beyond the comprehension of ordinary men---with the work itself.