Technical Papers Every Programmer Should Read (At Least Twice)
I don't mean to speak badly of this bibliography.  Of the papers in the list I've read, they're all great.  And I'll add the others to my list and make sure I get to them.<p>But I think the premise of the blog post is a little flawed.  Reading papers is a poor way to make yourself a better programmer.  Read them in spare moments, sure, but spend your time reading <i>code</i>, not paper. At best, these things will help you avoid some design mistakes in the code you write for yourself in your own sandboxes.<p>In the real world, you're dealing with code written by people who haven't read these papers.  And this is where you're going to spend all your time: maintaining and fixing and enhancing stuff that missed all the advice in the papers.  This is especially true of "day job" programmers, but it's true at startups too, even at seed-stage oens.<p>Admonitions to do stuff like re-read "Out of the Tar Pit" every six months is just bad advice to my mind.  It's a good way to convince yourself you're smarter than everyone else.  It's a bad way to get better at debugging.