You are young and so forgiven to have not included as #1 the seminal works of Donald Knuth, "The Art of Computer Programming", still as relevant today as it was in the late 60's and 70's. What he described is to this day true of the underpinnings of all we do, everything since is really decoration and elaboration. And I say this as a still active systems developer, familiar with and working with current SOC systems from DSP coprocessors on up, not as an old fogey left by the wayside and complaining about the youngsters today. Although they really don't know what it took to get here.
In the preamble the post discusses wanting to learn how to write enterprise-type code, but if we are going just good ol' CS books in general, no one can touch SICP. The definition of abstraction in there blew my mind.
SICP is amazing. The only bad thing I can say about it is that since it was my first CS textbook in college, it naturally became my measuring stick for "good CS book", which has nearly ruined most of the CS books I read.
I can't say enough good things about SICP. I'm currently working my way through it, and it's such a joy. Watching Prof. Abelson and Sussman's recorded lectures from the 80's is equally enjoyable because they're such good lecturers; thought-provoking and engaging.
Having recently revisited SICP, I am not nearly as impressed anymore as I used to be when I worked through it as a teenager. It aged badly (or perhaps, I outgrew it).
For algorithms, I like Skiena's Algorithm Design Manual. That's a practical-oriented book, where theoretical learning is mixed with anecdotes about real life problems solved.
The same cannot be said for TAOCP, but it certainly looks very good on a shelf. Practical usage? Limited. You don't need Knuth to learn basics of time complexity.
To my down-voter: TAOCP is essential foundation to understand the whys and wherefores of writing good code at any higher level; one must understand the mechanics and limitations of the systems one is using.
Hoping for Moore's Law to save your performance is not the way to do things.
Knowing about what goes into an ISA, about how operations map onto the hardware, about cacheing, memory virtualization and architectures, about in-order and out-order execution, multi-processor scheduling and synchronization, communications basics (on top of which all other protocols are built), distributed processing gotchas, etc etc, all play their part in writing efficient and effective code wherever.
Languages are tools, all are Turing Complete and can do no more than any other; which to choose for any function is a matter of convention and convenience. And what coding style to use is convention, and how to integrate with other programmers, how to manage projects, "Best Practices" and Patterns, all are conventions, and the degree to which they make the difference is a function of the quality of the involved programmers abilities, not a function of the style chosen. Hence my characterization of all the above as "Elaborations and Decorations". Most of the earlier hardware list also fit into that characterization, but the idiosyncrasies of each ISA and core architecture can have enormous impact on the final products' performance and need proper attention.
It is sad that after 50 years in the business I still know how these things work, and how to make them sing. It should not be so. But the technology has only gotten smaller and faster and has more immediate storage available and faster I/O and more elaborations and accelerations. No fundamental changes. Not that it doesn't blow my mind every so often, that what was a mere pipe-dream in the 60's is today mundane, or even so ubiquitous its underpinning have faded into the background. But it was pretty much already all down on paper in the 60's, just waiting on the capacity of technology SOA to catch up.
The list presented contained very little if any fundamentals. And without the fundamentals, the knowledge garnered is rote, founded upon shifting sands. Thus, I posit the books from which one learned those fundamentals should occupy top place in any such list. The knowledge garnered shapes every future thought on the subject, shapes every problem solving approach, shapes how you think about computers and computing at an internalized level.
In 50 years of commercial (if not commerce per se) experience (and continuing), every hire I've had the pleasure to work with has them, and every hire that frustrated and produced bad, unreadable, buggy, and inefficient code, did not.
That we have today billions of transistors in the space once occupied by one, and clock cycles thousands of times higher, and communication rates trillions of times higher (potentially anyway), is no excuse for not understanding how it all fits together. Today we need to do more with what we have, and so resources are always limited. Possibly a derivative of Parkinson's Law at work. Instead all too often I see bloat and the hope that tomorrows' machines will fix things. Tomorrow never comes, it seems.
As IIRC Piccasso (Dali?) is reputed to have told one young hopeful: "Come back to me when you can show me you can draw a straight line. Then I might believe those squiggles mean something".
This is a misguided ramble. TAOCP is a comprehensive reference of computer science, and archive documentation. It isn't meant as a textbook to read through. Nearly no one has read more than a few pages.
At the time it was a revelation. And I did too read all. I guess I'm no-one then, by your standards. I'd warrant you never read a dictionary in your childhood either.
No-one. Well then. Creds are perhaps in order.
So, now - 50 years experience, still working, very senior level tech equivalent to management, hardware and software designer from transistor days through graphical programming platforms. I started at the bit level and grew from there alongside the technology, all the way. Still surfing it.
At this age I think that stands for something. If I were no longer working or able to cut it you might have a point, but I've never got a job by sending in a resume - always by reference. I am still a valuable player today. My paycheck tells me that. Stuff in the field tells me that. Everyone I've ever worked with tells me that - and back it up with investment and salary. Two industries know my name (Datacomms and Music). To my surprise I built up a solid rep and no longer need to keep quiet abut stuff.
Consequential emergent philosophy of the Art.
I also think there's a difference between a ramble and an attempt at linearizing a parallel multi-dimensional thought. English is not good for this. Nor does ADHD help.
Knuth's works are also a multi-dimensional parallel linearization. Similar to though differently presented than Minsky's Society of Mind. Though they are both far better than I at doing that. The value comes after internalizing them, where your mind rebuilds the multi-dimensional structure and the interconnections become useful.
This might come as a surprise, but programming is also a multi-dimensional, parallel, multi-threaded mental activity. Internal knowledge organization of similar form is essential. It is fractal too, no depths too detailed or un-needed, no heights irrelevant, all present at the same time.
If you disagree about the need to know the fundamentals, well, good on yer, but you limit yourself. Tell me how it went when you are 67.
