READING PAPERS
I believe this paper was the first one that I tried to seriously read.
Looking back on it, it was pretty funny. Basically, I did the thing
that any geeky, hyper-serious, and clueless student would do: I
started highlighting any phrase that seemed interesting. By the the
end, my paper looked something like this:
Needless to say, utterly useless =)
I'm embarrassed to say that I actually showed this paper (with my
highlights) to the professor teaching my machine vision class, asking
him for advice on how to read papers. Looking back, I'm surprised he
didn't burst out laughing on the spot.
I've since accumulated more experience. Nowadays, I read most papers
fairly quickly. If the paper is in my area, I usually skip the
intro/related work (unless the paper has a very novel take on the
area), and go straight to the technical part of the paper. I try to
map the model/assumptions in the paper to work I've done/encountered
in the past, in order to understand what's new (if anything).
I read a few papers more carefully (typically because they're more
interesting/relevant to my research interests at the time). In these
cases, I struggle just like how I've always struggled, because
understanding new technical content is hard and takes time. I am able
to process certain things faster than before, but understanding truly
new stuff takes about the same amount of time as before. There are, of
course, shades of grey between these two extremes.
For me, the biggest difference between when I started out and now is
how quickly I can make a high-level pass over a paper to tease out the
main contributions, and to decide if it's something I want to
understand in detail. This also has the nice side-effect of me being
able to quickly write introduction & related work sections because
I've developed a nice global view on research in my area.
WRITING PAPERS
There are actually two things to consider here.
1) How do you approach a research project?
2) How/when do you decide what part of the project to package into a
paper submission?
I really want to emphasize this dichotomy because being too paper
driven can lead to bad/mediocre outcomes (since papers in of
themselves are not the goal, but rather scientific impact is).
When I was a junior PhD student doing my first research project, my
advisor decided on 1) for me, at least at the macro and intermediate
levels. At the macro level, he wanted me to work on interesting
extensions of an approach his group was working on (structural SVMs).
At the intermediate level, he wanted me to work an a specific
extension to an interesting application. Given the rather structured
nature of the project, it felt more like a super-glorified take-home
algorithms project. The project culminated in this paper. My advisor
had a lot of input in 2), helping me decide what to put into the paper
and what to leave out.
For my second project, my advisor explicitly asked me pick an
intermediate level project direction by myself. He basically told me
to scan through the SIGIR proceedings and identify some fundamental
technical problem that could be automated using machine learning.
After brainstorming together for about a month, we eventually settled
on a project that led to this paper.
After this, my advisor basically started treating me more like an
equal, and we started exploring high level research directions
together.
For me, 1) is very much tied to understanding trends in technology as
well as neighboring fields. For machine learning, example trends
include bigger datasets, or having humans in the loop a la
crowdsourcing. These trends are indicators regarding good research
directions to take your own field, since all fields have synergy with
each other. Believe it or not, writing research proposals for
fellowship/grant/award applications is actually very useful because it
forces you to synthesize these ideas into concrete research
directions.
Once you have a project and results worth writing a paper about, I
found that 2) becomes pretty easy with practice.
没有评论:
发表评论