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".