Any other entrepreneurs integrating this into their standard employee training manual?
Technical Papers Every Programmer Should Read (At Least Twice)
11–20 of 61 posts
Re: Technical Papers Every Programmer Should Read (At Least Twice)
#12I read a random sampling paper recently which took a simple problem and approached it in ways that were much more elegant than I did.
Its almost a toy problem but I found the paper really interesting:
http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.138.7...
Re: Technical Papers Every Programmer Should Read (At Least Twice)
#13"All papers are freely available online" Why not have links to each one?
Sorry. My Markdown syntax was bad. There are now links to the articles marked by ↗.
This is a great collection of papers, and I don't mean to downplay how happy I am to find it, but you might want to use a linking method that's more obvious, like having relevant text be blue and underlined. The principle of least surprise is important, usually more important than cleverness in design.
(Now I'm going to go off and read that Lamport paper.)
Re: Technical Papers Every Programmer Should Read (At Least Twice)
#14Re: Technical Papers Every Programmer Should Read (At Least Twice)
#15I read a random sampling paper recently which took a simple problem and approached it in ways that were much more elegant than I did. Its almost a toy problem but I found the paper really interesting: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.138.7...
Fun fact: I was asked to find a solution to this problem during an interview at a proprietary trading firm last year.
I wish I had read this paper before.
Re: Technical Papers Every Programmer Should Read (At Least Twice)
#16Re: Technical Papers Every Programmer Should Read (At Least Twice)
#17Nice collection of papers. Thanks for sharing!
Here is a set of papers about distributed systems, which I read in a course and found very useful to get good understanding of distributed systems research so far: http://www.cs.utexas.edu/~dahlin/Classes/GradOS/index.html
Re: Technical Papers Every Programmer Should Read (At Least Twice)
#18I 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.
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 code, not paper. At best, these things will help you avoid some design mistakes in the code you write for yourself in your own sandboxes.
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.
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.
Re: Technical Papers Every Programmer Should Read (At Least Twice)
#19I read a random sampling paper recently which took a simple problem and approached it in ways that were much more elegant than I did. Its almost a toy problem but I found the paper really interesting: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.138.7...
Fun fact: I was asked to find a solution to this problem during an interview at a proprietary trading firm last year. I wish I had read this paper before.
The algorithm for the simplest variant of that problem (take a single random sample from a list of a priori unknown length) can be derived by simple inductive reasoning. If the list has size 1, the problem is trivially solved. Otherwise suppose we have a list (x:xs) and we recursively solve the problem for xs. If all the recursion returns is the random sample from xs, we clearly have insufficient information to take a random sample from (x:xs), so we need to strengthen the induction hypothesis by having the recursion also return the length of xs. Let (r', n') be the random sample and length for xs. Then the result for (x:xs) is (r, n) where n = n' + 1 and r = x with probability 1/n or else r'.
Another way to derive this algorithm is to notice that any solution must implicitly or explicitly compute the length of the list as a byproduct. If you start by writing down the recursive function for computing the length of a list, composed with the straightforward recursive function for taking a random sample from a list of known length, you can apply a standard fusion and deforesting transformation to combine them into a single pass, and you end up with the same algorithm as above.
Here's a fun problem to ponder. Find the most frequently occurring element of a list in O(n) time and O(1) space. You may assume that this element occupies more than half of the list's entries.
Re: Technical Papers Every Programmer Should Read (At Least Twice)
#20Earlier quoted context omitted.
Fun fact: I was asked to find a solution to this problem during an interview at a proprietary trading firm last year. I wish I had read this paper before.
The algorithm for the simplest variant of that problem (take a single random sample from a list of a priori unknown length) can be derived by simple inductive reasoning. If the list has size 1, the problem is trivially solved. Otherwise suppose we have a list (x:xs) and we recursively solve the problem for xs. If all the recursion returns is the random sample from xs, we clearly have insufficient information to take…
>Then the result for (x:xs) is (r, n) where n = n' + 1 and r = x with probability 1/n or else r'.
Do you mean r = x:r' instead of r = x?