Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical Papers Every Programmer Should Read (At Least Twice)

blog.fogus.me

Post reply on HN
Print view View original

41–50 of 61 posts

Re: Technical Papers Every Programmer Should Read (At Least Twice)

#41

Post by 0x12 »

ajross wrote: post #18

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

Most programmers I know never read papers, they read plenty of code but the code usually sucks. The reason why it sucks is because it was written by programmers that never read papers and so the cycle continues.

If you don't start somewhere then you'll miss out on papers being an excellent source of knowledge about algorithms, datastructures and the like. They also introduce you to a more mathematical approach to problem solving.

More papers, less code, and if you read code for its educational value make sure it is excellent code.

Then go back to your daily drudge of fixing bugs in crappy code, hopefully transforming it into something more elegant along the way with the knowledge you pick up.

Read papers, read good code to educate yourself.

Re: Technical Papers Every Programmer Should Read (At Least Twice)

#44

Post by wglb »

ajross wrote: post #18

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

I would heartily disagree. As an example, reading about Vector Clocks by Lamport had an immediate effect on how I thought about a real-world problem, and it has stayed with me since.

My first reading of "GOTOs considered harmful" led to the phase of my career where I was all about structured programming. (For s perspective, much HLL programming then was in fortran with the three-branch IF-statement.)

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. The very best way to get better at debugging is to not put bugs there in the first place. The Tar Pit paper is one step in that direction. And it is important to keep at that because our habits keep trying to put state in.

So while it sounds like you are saying "get your inspiration from reading bad code", I suspect that you don't really mean that.

Re: Technical Papers Every Programmer Should Read (At Least Twice)

#45

Post by swah »

0x12 wrote: post #41
ajross wrote: post #18

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

Most programmers I know never read papers, they read plenty of code but the code usually sucks. The reason why it sucks is because it was written by programmers that never read papers and so the cycle continues. If you don't start somewhere then you'll miss out on papers being an excellent source of knowledge about algorithms, datastructures and the like. They also introduce you to a more mathematical approach to pro…

What about books ? Aren't they condensations of papers? :)

Re: Technical Papers Every Programmer Should Read (At Least Twice)

#46

Post by spacemanaki »

zephyrfalcon wrote: post #43

What would be useful is a site that collects links to CS papers, then for each paper lets users (who presumably actually read that paper) comment on it, and/or rate it. Or does such a beast already exist?

Well there's a thread over on the CS Stack Exchange about favorite papers, but it sort of doesn't fit what you describe:

http://cstheory.stackexchange.com/questions/1168/what-papers...

Re: Technical Papers Every Programmer Should Read (At Least Twice)

#47

Post by ajross »

wglb wrote: post #44
ajross wrote: post #18

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

I would heartily disagree. As an example, reading about Vector Clocks by Lamport had an immediate effect on how I thought about a real-world problem, and it has stayed with me since. My first reading of "GOTOs considered harmful" led to the phase of my career where I was all about structured programming. (For s perspective, much HLL programming then was in fortran with the three-branch IF-statement.) Admonitions to d…

The very best way to get better at debugging is to not put bugs there in the first place.

You realize how terribly naive this is, right? Everyone, no matter how smart, not matter how experienced, and no matter how many papers they read, is going to put giant whoppers of idiocy into their code on a regular basis. And finding these is where we spend all our time.

Your answer is an echo of the blog post: you're acting as if the act of writing code is the thing that needs optimization. It's not, though maybe it seems that way early in your career. Code (successful code, anyway) lives long after it's written, and that phase is vastly more expensive. And papers don't help there. Sorry, but they don't.

Read the papers, they're good. But stop pretending that they're the path to enlightenment. Our profession, ultimately, isn't about enlightenment. It's about results.

Re: Technical Papers Every Programmer Should Read (At Least Twice)

#48

Post by charlieok »

zephyrfalcon wrote: post #43

What would be useful is a site that collects links to CS papers, then for each paper lets users (who presumably actually read that paper) comment on it, and/or rate it. Or does such a beast already exist?

Mendeley [1] does some of what you're talking about. Primarily it's a way to organize your own collection of papers and access them from native or web apps on various devices. It also has some social features, like connecting users with similar interests and sharing tags on papers.

Its "Computer and Information Science" category [2] lists the papers with the most "readers" which I think in this case means "Mendeley users who have added this paper to their collection". Its most read paper in that category is the MapReduce paper [3]. Oddly, as I look at it now, I don't see a feature for rating or commenting on the paper, which could be a useful addition.

Of course, the authoritative method of rating papers is citations of other papers, right? That's what led to PageRank after all, and most of the main sites for finding papers have used citation counts for a long time.

[1] http://www.mendeley.com

[2] http://www.mendeley.com/computer-and-information-science/

[3] http://www.mendeley.com/research/mapreducemerge-simplified-r...

Re: Technical Papers Every Programmer Should Read (At Least Twice)

#49

Post by 0x12 »

swah wrote: post #45
0x12 wrote: post #41

Earlier quoted context omitted.

Most programmers I know never read papers, they read plenty of code but the code usually sucks. The reason why it sucks is because it was written by programmers that never read papers and so the cycle continues. If you don't start somewhere then you'll miss out on papers being an excellent source of knowledge about algorithms, datastructures and the like. They also introduce you to a more mathematical approach to pro…

What about books ? Aren't they condensations of papers? :)

What about readers digest? Aren't they condensations of books? :)

Re: Technical Papers Every Programmer Should Read (At Least Twice)

#50

Post by wglb »

ajross wrote: post #47
wglb wrote: post #44

Earlier quoted context omitted.

I would heartily disagree. As an example, reading about Vector Clocks by Lamport had an immediate effect on how I thought about a real-world problem, and it has stayed with me since. My first reading of "GOTOs considered harmful" led to the phase of my career where I was all about structured programming. (For s perspective, much HLL programming then was in fortran with the three-branch IF-statement.) Admonitions to d…

The very best way to get better at debugging is to not put bugs there in the first place. You realize how terribly naive this is, right? Everyone, no matter how smart, not matter how experienced, and no matter how many papers they read, is going to put giant whoppers of idiocy into their code on a regular basis. And finding these is where we spend all our time. Your answer is an echo of the blog post: you're acting a…

You realize how terribly naive this is, right? This is out of line.

It's not, though maybe it seems that way early in your career I am no longer early in my career. I recently viewed code that is in production today that I wrote in 1966. Most of it had survived. And the hours I invested in writing it swamped any maintenance hours put into it after that.

... put giant whoppers of idiocy into their code on a regular basis. And finding these is where we spend all our time. Perhaps you do; my code comes out better than that. I attribute the difference to having read papers. I am not pretending.

Post reply on HN