I wonder how many people actually read the books they were suggesting.
Like here on HN, Art of Computer Programming gets mentioned a lot. But I've not met anyone who has actually read it. And I own a copy. It's so hard of a read that I am just going to assume anyone who says they did is either lying or Donald Knuth.
I'm suspect of books as a means of information conveyance. They make great mediums for narratives, but narrative is too slow for technical writing. Similarly, I dislike videos, podcasts, and conference talks. Technical writing should be a wiki-like document where terms expand in-place. Start super high-level. Always written in clipped, imperative style. Single line per fact. Like mathematical proofs, but maybe in reverse.
I've finished and very much enjoyed the first volume, which is equivalent to the curriculum in any first year compsci course from what I've seen of university lecture schedules (Data Structures such as Lists/Stacks/Queues/Trees/Arrays,GC,'helper functions' and program design,O-notation analysis,testing and debugging w/trace routines, I/O algorithms) but of course in much more detail with much harder problems.
To understand the first few hundred pages on mathematical preliminaries, the books "The Art and Craft of Problem Solving" by Zeitz and "Concepts of Modern Mathematics" by Stewart, were essential, both of which were recommended here in other book list posts. I also had already read the CS:APP book which covers x86-64 assembly so the MIX introduction was fairly straight forward. http://csapp.cs.cmu.edu/
A book for me that was hard to read, is this book: http://www.cs.cmu.edu/~rwh/pfpl.html Practical Foundations for Programming Languages each page I have to translate with the notation guide, and is a research exercise searching Wikipedia for additional material.
There's something to be said for reading "a great book" from cover to cover. It is really an investment of time, effort and discipline over many days.
I think people (and I include myself) buy such books often with an aspirational intent, to spend that "perfect" weekend or weekends deeply ensconced in the subject matter and coming out of the reading as a different, better and more skilled person. It never happens that way, of course. We're just trying to re-live some past time as students where the world was an oyster of knowledge. For the most part memories of those days are grossly inaccurate, merely softened into nostalgia by the passage of time.
In reality, many of us behave like monkeys continually zapped by shock-collars just trying to keep up with shit that never works right and always living in a profound deficit of knowledge, while drowning in information.
Still, its good to have books, and worthwhile to take insane measures to get alone-time to read them. The short practical ones are best. Comprehensive reference books are good too because you can read just what you need while ducking from life's flying shit.
I've read the first three volumes. And recently when paring down my collection, it went out. Sorry, Donald, but you've got too much about multi-phase tape sorts and not enough about current programming.
I started volume four but couldn't get my head around the first page, and am very dubious that plowing through it would have any real value.
Like here on HN, Art of Computer Programming gets mentioned a lot. But I've not met anyone who has actually read it. And I own a copy. It's so hard of a read that I am just going to assume anyone who says they did is either lying or Donald Knuth.
I'm suspect of books as a means of information conveyance. They make great mediums for narratives, but narrative is too slow for technical writing. Similarly, I dislike videos, podcasts, and conference talks. Technical writing should be a wiki-like document where terms expand in-place. Start super high-level. Always written in clipped, imperative style. Single line per fact. Like mathematical proofs, but maybe in reverse.