
Technical Papers Every Programmer Should Read at Least Twice (2011) - altern8
http://blog.fogus.me/2011/09/08/10-technical-papers-every-programmer-should-read-at-least-twice/
======
platz
There is very little all programmers should be required to have in common. The
field is just that big now.

9 times out of 10 a list like this includes a treatise on floating point
number representation, which while useful, probably isn't of utmost importance
in the 21st century, but hey, at one time folks thought that _was_ required
for 'all programmers' to read. At least this list does seem more up to date
and relevant.

I just wish we'd stop with 'all X should' titles. Its demeaning and
inaccurate.

~~~
momo-reina
Actually I'd argue that there are quite a few things that programmers should
have in common, if by programmers we're talking about serious
engineers/computer scientis[1] and not "amateur-hour web designers"[2].

Knowledge of the fundamental concepts talked about on that list of papers, and
the history therewith, is what allows us to go past the current level of
engineering and actually reach greater heights. Most of the emphasis nowadays
is spent on knowledge of specific toolchains, frameworks, etc, instead of
actually learning WHY and HOW these things work.

From that basic foundation you can then go into any field and learn the
semantics, details, and problem-specific techniques to deal with the problems
presented. Without that foundation, we're all just floundering around,
becoming proficient in using these tools without actually KNOWING how they
work and therefore unable to take them to the next level.

[1] - A conversation with Alan Kay
[https://queue.acm.org/detail.cfm?id=1039523](https://queue.acm.org/detail.cfm?id=1039523)
[2] - JavaScript isn't Scheme
[http://journal.stuffwithstuff.com/2013/07/18/javascript-
isnt...](http://journal.stuffwithstuff.com/2013/07/18/javascript-isnt-scheme/)

~~~
jnbiche
"not "amateur-hour web designers"

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.

~~~
momo-reina
Perhaps the comment came out wrong, let me try to be a little clearer.

I'm not trying to create separate categories between front-end, back-end,
desktop, CLI, and systems engineers. The distinction I am trying to make
though is that yes, while Computing has become a vast field, there simply are
some basic fundamental skills that are absolutely required if we want to go
beyond our current level of achievement.

These are things that you have mentioned: deep knowledge of algorithms, data
structures, software engineering, computer architecture, etc. This is
absolutely the MINIMUM requirement Without understanding these things, we will
stay at this present level of software engineering forever. Sure we will have
mastered the tools, and the current programming-paradigms that these tools
teach us, but we will not be able to advance.

Whether one programs in JavaScript, Forth, Common Lisp, or even BASIC isn't
the issue. The point that Fogus's post is trying to get across, or at least
what I have taken away from it, is that most "serious" programmers are
incredibly lacking in what is considered basic foundational knowledge. What
field one specializes in is irrelevant, there is just some stuff that everyone
has to understand, not necessarily in the way that a specialist in the field
does, but at least have more than passing, cursory knowledge of it.

~~~
jnbiche
Fair enough. We're are on the same page, after all.

------
frakkingcylons
I think Communicating Sequential Processes [0] by Hoare is another landmark
paper that should be on this list for its perspective on organizing concurrent
processes. This was actually required reading for the concurrency section of
my undergrad operating systems course.

[0]:
[https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf](https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf)

~~~
dvanduzer
"The practice of supplying proofs for nontrivial programs will not become
widespread until considerably more powerful proof techniques become available,
and even then will not be easy. But the practical advantages of program
proving will eventually outweigh the difficulties, in view of the increasing
costs of programming error."

The Hoare paper actually linked is hopelessly outdated, despite being an
interesting historical artifact.

~~~
ploxiln
I might call it "sadly" outdated... not that I'm a fan of provably-correct
programming (I've never done it, I just fix systems and networking software),
but the seemingly modern comfort with buggyness and sloppy implementation...
funny or sad, who knows

------
KevinEldon
It's interesting to read the HN comments on this post now and what others have
said previously.

[https://news.ycombinator.com/item?id=3382962](https://news.ycombinator.com/item?id=3382962)
[https://news.ycombinator.com/item?id=2979458](https://news.ycombinator.com/item?id=2979458)

~~~
waterlesscloud
Wow. That really is a quite revealing comparison.

~~~
Semiapies
Part of it might be that this was dropped on a Friday night, US time.

~~~
3rd3
There is also the fact that the first condensation seeds of discussions on HN
are largely determined by chance.

------
notacoward
Eight out of ten are about programming languages, and strong on the functional
side to boot. It's not that these topics aren't important, or that they're not
great papers, but isn't that a bit too heavily skewed toward one area?
Shouldn't at least one of those top ten be more directly about security, or
performance, or some other kind of idea rather than the notation we use to
express ideas?

Yeah, I know, make your own list. Maybe I will. Nonetheless, the author
specifically mentions "cover a wide-range of topics" as a goal and this list
fails to meet that goal.

~~~
dj-wonk
Yes, there is an emphasis (and bias!) towards functional languages and
distributed systems. Yes, Fogus' intent is to raise awareness of these
concepts. Yes, other people would have different lists. Yes, the list could
have more breadth.

Personally, I'd like to see a concept map of essential computer science topics
combined with some of the top papers and books that cover each. It could be
implemented as a curated collapsable directed graph.

~~~
tekacs
> Personally, I'd like to see a concept map of essential computer science
> topics combined with some of the top papers and books that cover each. It
> could be implemented as a curated collapsable directed graph.

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. :/

------
jvreeland
It's weird that "What every programmer should know about memory" Isn't on
here. Even for languages that manage memory for you understanding the hard
limitations and basic operations used to access and manipulate memory is
certainly useful.

~~~
Matumio
This is an excellent read, but I disagree with the title. It's a must-read for
people interested in CPU architecture and for programmers who, after
profiling, still consider doing micro-optimizations. E.g. if you seriously
think about reordering your struct members for faster access. If you're
building a web service, skip it.

~~~
EdwardCoffin
I think it is a useful read for people doing any kind of programming at all,
in that it might discourage them from attempting optimizations that seem
obviously good, and might have _been_ good, if they were running on 20 year-
old architectures, but these days just make the code more convoluted to no
gain.

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.

------
jaryd
I would recommend this one for historical purposes:
[http://insecure.org/stf/smashstack.html](http://insecure.org/stf/smashstack.html)

~~~
grobinson
This is an excellent paper but it does require a prior understanding of the
stack, addressing, buffers, pointers, etc. It would be really nice if there
was an article or blog post designed for people who want to read this paper
but don't have the prior knowledge that's required to understand it.
Unfortuntely I don't know of any. HN?

------
dvanduzer
Why _this_ Hoare paper and _this_ Lamport paper? A list of ten is a bit long
considering how much background material is required reading for every single
entry.

------
bdamm
Any list without Shannon's 1948 "A Mathematical Theory of Communication" is
just not a good list. Sorry.

[http://cm.bell-
labs.com/cm/ms/what/shannonday/shannon1948.pd...](http://cm.bell-
labs.com/cm/ms/what/shannonday/shannon1948.pdf)

The foundation of information theory. It is, by far, the most astonishing
paper I have ever read. Far more astonishing than Lamport's famous conclusion
about clocks. It is the kind of paper that causes a soul rift when read
thoroughly.

~~~
anjbe
I’m partial to his Master’s thesis, “A Symbolic Analysis of Relay and
Switching Circuits.” It literally invented digital computing. As an electrical
engineering student it blows me away that one guy’s thesis (he was 21!) can be
fundamental to so much.

------
kashif
Most seem to be available here - [https://github.com/papers-we-love/papers-we-
love](https://github.com/papers-we-love/papers-we-love)

------
angry_octet
I love that even HN has listicles, and I would rate this one as at least on
par with [http://www.lifehack.org/articles/lifestyle/21-things-you-
are...](http://www.lifehack.org/articles/lifestyle/21-things-you-are-doing-
wrong-every-day.html)

------
ashish01
Can some please do a similar list for machine learning and also for maths
relevant to ML?

~~~
stillsut
Probably the most famous papers is Breimen's "The Two Cultures". The
rejoinder's from Cox and Hoadley add two additional perspectives from long
careers.

~~~
melchebo
Breiman, btw. Link to paper:
[http://projecteuclid.org/euclid.ss/1009213726](http://projecteuclid.org/euclid.ss/1009213726)

------
picardo
I had a dream about one of these papers tonight (seriously), so I come to HN
and find this post. Pretty amazing coincidence. :)

------
hotgoldminer
Has anyone else explored the rest of his site? Good posts, workable, no fuss
design. All good work here. Keep it up!

~~~
jcr
fogus is a well known HN contributor.

[https://news.ycombinator.com/user?id=fogus](https://news.ycombinator.com/user?id=fogus)

------
jobenex
Agree with platz

------
Yadi
#oly $#it! I have read these papers, all of'm! WHAT! Haha that is so accurate
LOL!

Great stuff! But there are way more important whitepapers to be honest. I
can't really think of the others right now, but if you go to the Digital
library from ACM / IEEE, you can find really good stuff.

