Technical Papers Every Programmer Should Read at Least Twice (2011)

I would disagree (with the extent of their applicability and general usefulness). Not that this isn't somewhat useful to many or most programmers -- you may certainly be right about that -- but there are other subjects (like data structures, for example) that are probably a lot more useful, and serve as much more fundamental underpinning for common technologies[1]. So, yes, we'd all benefits if more programmers learned this stuff, but we'd benefit even more if they spend their time on even more important/general CS topics.

Because programmers spend much of their time in code they sometimes tend to place too much emphasis on code over working, well-behaving, performant running programs. Producing such programs requires a lot more than "the right" programming style: it requires a good understanding of hardware, of requirement analysis, of common failure modes, of algorithms and data structures. Programming style (or language) is just a part of what's required, and probably among the least important parts.

The widespread belief among PL people is that "good" programming languages (for your own definition/preference of "good") promote good working software, but not only has that never been proven, there isn't much evidence to suggest this is even true at all (now, I'm not saying it's not true, but just playing devil's advocate and pointing out it isn't evidently true).

[1] Proof: binary (and other types of trees) trees are used in every programming language, while classes, object, higher order function or monads are most certainly not; ergo: you can certainly program -- and produce good, working software -- without classes/object/high-order-functions/monads, but you can't produce good software (in general, that is), without knowledge of trees (and/or other data structures).

Perhaps you're confused. Most people who refer to themselves as "web designers" aren't meant to be or and aren't trying to be computer scientists or engineers. Many of them have a graphics design education, or taken inspiration from that tradition. Some of the more technically-minded of them can do basic coding, but most of them stop at HTML and CSS. But they're better than I am at UI/UX, and visual design, because that's what they do. They're not meant to be computer scientists.

If you mean web-application developers, however, I'd urge you to take a look at some of the stuff that is being done on the front-end these days. (not to mention the fact that this blog post was written by a Javascript expert)

Yes, there are some people who have drifted into their jobs and are little more than cargo cultists, although some of the more talented and curious of them do make the upgrade to serious professionals. But by far, most of the people I've worked with recently on front-end jobs have had a rigorous computer science education, with an excellent knowledge of data structures, algorithms, software engineering, and computer architecture. The fact that they're working on the front-end, in Javascript, is incidental. In their spare time, and if they're lucky, on some in-house stuff, they might prefer working in Haskell, or maybe Clojure. But much like C in past decades, the web is ubiquitous, and any serious developer of this era must know how to work in it. We don't all have the privilege of getting paid to write Scheme.

But I do share your opinion that there are certain foundational concepts and knowledge that all professional programmers should have in common, including some of the papers referenced.

Unrelated to numeric computing, my favourite thing would be Butler Lampson's Hints for Computer System Design.

I've tried building one of these before, both for CS and for Maths. Funnily enough formatting, displaying and making it accessible (whilst retaining enough data) was the time-consuming issue, despite all the tech around for handling graphs. :/

I know that this is the kind of effect the paper had on me (I spent a lot of time carefully reading it shortly after it was published), and now I almost never use what knowledge I gained from it to make performance optimizations, but it does frequently discourage me from attempting optimizations that I now know would probably not have the desired effect.