Confessions of a researchaholic

Students take courses in college, and do research in graduate school.

Taking courses and doing research share some common intellectual underpinnings. On the other hand, they are also very different. Different enough to make some college superstars completely fail in graduate schools.

When you take a course, everything is pre-designed and deterministic. You follow the instructions. And if you are smart and hardworking enough, you get good grades.

When you conduct a research project, very little is known a priori. The process is ambiguous and stochastic; your assumption may be wrong, your experiments may fail, sometimes you might not know what you are doing, and in the end your papers may get rejected. Being smart and hardworking can help. But if you have to follow clear instructions and you expect deterministic outcomes, you probably will not enjoy or be very good at research.

This is probably why, in my personal experience, the best research students might not have the best GPA, but they are usually creative, motivated, tough, and (most importantly) can get things done no matter what happens.
(Perfect GPA can be a reflection of conforming personality, which is not suitable for research. On the other hand, bad GPA is usually a reflection of intellectual or personality problems.)

The transition from undergrad to grad school is not always easy for everyone. My suggestion is to adopt the research mentality as early as possible. In particular, do not waste your time on courses; all you need is to pass the minimal requirements. If you have to, take courses that are research or project oriented. And start your research as early as possible, so that you will have more time to learn and adjust, and to accommodate all the potential failures and setbacks.

What

Stage 1: I will train your basic skills through a series of pet projects (e.g. building a mini software system or reproducing a paper). You are supposed to complete all these entirely on your own.

Stage 2: I will then directly take you to a real project aiming for the best venue of your field. I will work very closely with you on everything.

Why

I only have time for the best projects with the best students. The above 2-stage process is designed as a consequence.

I understand this is not an ordinary methodology. But experiences indicate that it is very effective in helping all students. In particular, the good ones can learn and publish as quickly as possible, while the not-so-good ones can realize as early as possible that they should explore other career options.

I disagree with the usual process of gradual bring-up by submitting to lower tier venues. This can spoil your mentality and motivation, as you will not work as hard as you should and grow as fast as you could. And even if you need non-top publications, it is faster to have those as failed attempts for top venues than direct submissions to lower venues.

For those of you who are not my internal or primary students, your primary adviser should have the final say about your study plan. Just come to me when you are ready for stage-2.

Unfortunately, your paper was rejected by your favorite venue.
Now what? The decision for the next step depends on review opinions and your preferences.

It is not hard science: reviews are stochastic and humans are irrational.
(See earlier posts about rejections, and how to deal with them.)

So, the first thing is to figure out how much you should trust the reviews and your gut feelings.
Sometimes the reviews are right; maybe your paper is really not suitable for that venue (e.g. off topic, not enough contribution) and it is better to choose another venue.
But sometimes they are not; I have at least one submission that was summarized as “not having enough contribution” and I just went ahead with resubmission and the paper got in.

It also depends on whether you will enjoy continuing the work, and whether you think you can make significant improvements. If both conditions hold, it is probably a good idea to ignore the reviews.

Finally, consider opportunity cost. Given the same amount of time and efforts, you can either (1) resubmit the paper to your most favorite venue or (2) submit it to a lower tier and start a new work. Which one (you think) will make you happier and more productive?

PS: see my collaboration policy.

It is usually a very good idea to share the code and data along with our published papers. This will make it easier for others to test, understand, reproduce, and compare against our methods, which in turn can make us more popular, our papers more widely cited, and our technology more likely to be adopted by the industry and turned into real products.
Code and data repositories are also an important part of evaluating job applications.

(I have open sourced most of my first/single-authored projects, except my first 2 SIGGRAPH papers for which I could no longer find the code in the school server, which I greatly regret.)

Ideally the code should be in high quality, but even if not, sharing it can let others have a chance to improve the code (and motivate us to write good code).
It is fair to say that the code and data are no less important than the paper.

Some things to watch out for include institutional and legal constraints, such as trade secrets, copyrights, and patents, and not yet published future ideas.
These can be planned and managed via different git branches (e.g., a public branch that is gradually merged from a private branch).

In a nutshell, a demo should properly demonstrate technical aspects with sufficient artistic appeals.

The technical part is usually more important, and can suffice alone for many science and engineering disciplines. However, the artistic part is also very important for graphics and HCI, or any fields which involve direct human perception and consumption.

Demos usually take a lot of time and efforts, on top of the usual workload in ideation, writing, algorithm, implementation, and experimentation. And whether you like it or not, a solid and novel algorithm cannot be adequately assessed or appreciated by the readers if it is not demonstrated through proper demos.

Thus, designing demos is kind of an art. Below are recent suggestions from Sylvain Lefebvre which I have found to be excellent.

A guideline that worked fine for me is to consider whether 1) the result demonstrates the technique properly and 2) the result looks just good enough that it appears useful; in particular we want to avoid people think that the example is contrived to only show the advantage of our approach.

The problem is that 1) and 2) sometimes compete with each other (e.g. a fantastic rendering possibly making it hard to properly see the motion, etc.). Also we do not want to spend too much time on 2), only enough that people will think that it is convincing.