Live data from Hacker News

How to Read a Paper (2016) [pdf]

blizzard.cs.uwaterloo.ca

11–20 of 44 posts

Re: How to Read a Paper (2016) [pdf]

#11

I sometimes do an exercise with my students where I give them a paper and ask them to tell me in 5 minutes what is the research question and the answer. Usually works well (if the paper is well written), and shows hem that they can get a good grasp of papers without spending hours reading them.

My experience from journal clubs is that strategies like this just encourages parroting whatever is claimed without thinking critically.

Re: How to Read a Paper (2016) [pdf]

#13

If papers were written better, you might not need to read them over 3 times. There should be a paper called "how to write useful headlines for your paper." "first pass" "second pass" "third pass" should be replaced with unique, useful, preferably memorable headlines. For instance: "Quick scan" "Deeper but ignore details" and "Challenge every assumption in every statement" Then you haven't wasted the attention those b…

This is not true. Some of the best papers ever, I have benefited from reading many times, more than three.

Re: How to Read a Paper (2016) [pdf]

#14
I'd like to present a fourth option, the "0-pass":

Don't read most papers. Don't feel bad about not reading them, because in general they are terribly written.

Instead, read follow-on work which resynthesizes the ideas in these papers for a popular audience.

Re: How to Read a Paper (2016) [pdf]

#15

On the writing side of things, I really enjoyed this talk: https://www.youtube.com/watch?v=L_6xoMjFr70 "How to Write Papers So People Can Read Them"

My advisor (Voicu Popescu) wrote a couple of nice materials about "How to Write a CS Paper". The emphasis is mostly on how to do it in the computer graphics field, but perhaps it's applicable to other CS domains too:

In prose form: http://webarchiv.ethz.ch/digitalartweeks/web/uploads/DAWIntr...

In slide form: http://spaf.cerias.purdue.edu/classes/Popescu.pdf

Re: How to Read a Paper (2016) [pdf]

#16

I was all ready to mock this by saying how most papers get only 1) Read the abstract, 2) Read the conclusion, 3) Look at the graphics, from me. Turns out that it's basically what the paper says, but then goes into more detail about going into more detail. Worth at least a second pass :)

It's how I got through over 10,000 papers on IT and INFOSEC. When they're well-written, I could look at the abstract, a select bit of details, related work, and conclusion. Would take me about a minute or so a paper once I got good at it. Sometimes less. Some papers were more complex or just not well written where it took significantly more time to evaluate them. All in all, though, the speed reading methods save a t…

I assume you're talking about a time frame of many years.

Re: How to Read a Paper (2016) [pdf]

#17
This part was most interesting to me:

"Incidentally, when you write a paper, you can expect most reviewers (and readers) to make only one pass over it."

I understand reviewers are busy, but we depend on peer review to filter out bad or poorly-researched material. I don't think one pass is enough.

Obviously, so does the author.

Re: How to Read a Paper (2016) [pdf]

#18

I was all ready to mock this by saying how most papers get only 1) Read the abstract, 2) Read the conclusion, 3) Look at the graphics, from me. Turns out that it's basically what the paper says, but then goes into more detail about going into more detail. Worth at least a second pass :)

It's how I got through over 10,000 papers on IT and INFOSEC. When they're well-written, I could look at the abstract, a select bit of details, related work, and conclusion. Would take me about a minute or so a paper once I got good at it. Sometimes less. Some papers were more complex or just not well written where it took significantly more time to evaluate them. All in all, though, the speed reading methods save a t…

It typically takes much longer to actually understand the contribution of a paper in engineering fields (EE, for example). Of course, it depends on how much background you have prior to reading the paper.

Re: How to Read a Paper (2016) [pdf]

#19
post #16

Earlier quoted context omitted.

It's how I got through over 10,000 papers on IT and INFOSEC. When they're well-written, I could look at the abstract, a select bit of details, related work, and conclusion. Would take me about a minute or so a paper once I got good at it. Sometimes less. Some papers were more complex or just not well written where it took significantly more time to evaluate them. All in all, though, the speed reading methods save a t…

I assume you're talking about a time frame of many years.

At least six. Maybe more. Obsessively, too, as it was my grand challenge problem to solve all of it with a holistic solution. Got pretty close conceptually from a number of angles. End result was software or especially hardware options will need to be developed by specialists at significant cost. Now, I still collect the science while looking at marketing or development strategies a bit more.

Re: How to Read a Paper (2016) [pdf]

#20
post #18

Earlier quoted context omitted.

It's how I got through over 10,000 papers on IT and INFOSEC. When they're well-written, I could look at the abstract, a select bit of details, related work, and conclusion. Would take me about a minute or so a paper once I got good at it. Sometimes less. Some papers were more complex or just not well written where it took significantly more time to evaluate them. All in all, though, the speed reading methods save a t…

It typically takes much longer to actually understand the contribution of a paper in engineering fields (EE, for example). Of course, it depends on how much background you have prior to reading the paper.

The background accumulates as you thoroughly read them. You can understand a lot without knowing all the specifics. The good papers will usually explain the challenges, approaches so far, their weaknesses, their solution, and future work that's essentially the solution's weaknesses. One can get pretty far with that. Even formal verification papers were easy to follow on general idea of their methods or results without know the specialist stuff. Same with digital design. I only started getting slowed down, ineffective, or stomped when it was about analog or RF papers. It's why I keep saying one might not be able to cheat those. Not entirely, anyway: my abstract predictions of techniques like A2, the fab material mod, semi-automated synthesis with stochastic methods, or chaining gates together in tamper-resistance show my almost detail-less mental model is still better than nothing. I already had mitigations for two just guessing something might happen with that mental model. ;)
Post reply on HN