Confessions of a researchaholic

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.

First of all, if you follow my advices, you are not likely to fail. (See here for potential ways of failure.)

However, research is inherently unknown and thus risky. Nobody can predict the future. There is a natural attrition rate for PhD students (analogous to the natural unemployment rate for workers).

So, if for any reason you cannot complete your PhD, it is not as big a deal as you would imagine. (Plenty students in my grad school did not finish their degrees, and some of them went out to found companies, e.g. Yahoo and Google.)

For my internal “discontinuing” PhD students, here are your options:

. Find another professor in the department/school willing to take you

. Transfer from PhD to MS/MPhil

. Just walk away

In any case, I will do my best to help you transition to the next stage. But I cannot guarantee anything.

This figure illustrates how I collaborate with each student.

There are several main layers of a research project: idea creation, algorithm design, system implementation, and experimentation + results production. They are all wrapped up and glued together by presentation, which includes paper writing, video production, and (conference) talk.

For a beginner student, I would expect you to completely take charge of the implementation and production (including video), given the main ideas and algorithms as described in a paper draft (as part of the presentation). We could discuss anything you like, but you should be able to handle all the implementation and production details (e.g. I am not supposed to look into your code). Otherwise, you are not ready for research.

As you progress, I would expect you to be able to take charge more tasks at the higher layers. Idea creation is the most difficult and only a few can pull that off, but my experience is that a decent senior student can at least take part in algorithm design and paper writing.

To all these students who want to do data mining and think you have to join a database group:

I do not miss you at all, because you are just following trends instead of making your own decisions. Independent thinking is a necessary quality for succeeding in research. And you probably do not even comprehend the meaning and scope of data mining; I can find much more interesting ideas and applications in graphics and HCI than database.