Confessions of a researchaholic

Managing project is a huge topic that involves multiple aspects. This post focuses on one specific aspect, on how to manage and ensure progress. To me this is the most important aspect, because a project that is not done is worth nothing.

My strategy is very simple: use schedules to manage progress.

\paragraph{What}
Here is a quick example.

First milestone demo: October 17, 2012.
(A milestone is a demo that can show the project (1) is of SIGGRAPH potential and (2) is likely to be completed.)

Demo production (assuming we have 3, each with complete and concrete descriptions):
. Demo 1: November 1, 2012.
. Demo 2: November 16, 2012.
. Demo 3: December 1, 2012.

First complete paper draft: December 17, 2012.
(SIGGRAPH is not just about getting things done; it is a refinement progress towards perfection. My hope is to have a one month margin, even though few of my projects, mostly first authored by myself, have made this.)

SIGGRAPH 2013 deadline: January 17, 2013.
(Hard deadline; everything has to be done before this.)

\paragraph{How}
The schedule should be drafted, usually by the first author student, in the beginning of the project, and constantly updated and maintained throughout the project progress. All team members will look at the schedule and agree with its content.

The most important part is to make sure you actually meet your schedule. Do not let anything slip. Otherwise, it will not work.

Of course, research, or any project, can and will bump into unexpected snags. It is also not possible to accurately predict the amount of time needed for every item. The key is to keep the schedule as accurate as possible. For example, if you originally think demo 2 above will take only 2 weeks but it ends up taking 3 weeks, you should question whether you are too optimistic about your schedule and allocate more time for other items.
(If you find yourself not being able to meet the deadline, it means you probably have to speed things up by either working harder or working more efficiently. But the good thing is that you realize this early rather than late.)
As you become more experienced, you will also become more accurate in managing and predicting schedules. Without this practice, you will less likely learn this very important life skill.

I guess it probably very hard to fully comprehend what I mean here. If you are my student, you will learn this through a lot of practice with me.

\paragraph{Background}
I learned this through my NVIDIA days. One thing I find particularly proud about NVIDIA is that to my memory *not a single product* has ever been delayed during my stay. This was in sharp contrast to ATI, the (then) fierce competitor to NVIDIA, which (for reasons I do not know) constantly bumped into product delays. The rest is history.

The way the NVIDIANS did it is like this. Everybody and their brothers used schedules to manage progress, and slipping a milestone is considered a more serious crime than shooting someone. The CEO dropped in group meetings constantly and unannounced, and called out those responsible for delays. (Trust me, you will prefer being shot rather than getting called out.)

I like to list one most important thing I learned with every one of my jobs. And for NVIDIA, it will be project management. I do not think I will have learned this if I started as a professor immediately after school.

Culture is the hardest thing to reproduce, adapt, or change for an institution. Thus, it is best to get it right in the very beginning.

As I am building my very first internal research group, the culture I want to instill is “have fun and be awesome“. I realized, through interviewing hundreds of students (within just one year) and working with my first batch of internal students so far, that it is the human nature to get attracted to the “fun” part much more easily than the “awesome” part.

Thus, I have to be rigorous in enforcing the culture, especially on “awesomeness”.
If I can affect my initial batch of students, they can in turn propagate the culture both spatially and temporally, such as other labs/schools and future students.
If I cannot, none of these will happen, and I might as well find something else worthier my time.

Expectation for my internal HKU PhD students

How I handle failed internal PhD students

(This post, as many others in this blog, was inspired by recent events and student questions.)

One of the most important principles for a happy life is to know what really matters. This can help you minimize efforts and maximize rewards.

If you are a PhD student, the most important thing is your research. So focus on getting good publications. There are other things that matter to some degree but are much less important, such as teaching experience for those who want to become professors, as well as those that are not important at all but made appear to be so by others for their own peculiar reasons, such as taking courses. None of these should take precedence over your research.

If you are a professor in a research university, what really matters is (again) your research. There are other things like teaching, services, funding, etc. that better not suck but should never take precedence over your research.

(June 2 2016 add on)
If you are a computer scientist, the most important thing is to build useful products. The ultimate measure of a research is its practical impact, not academic publications.
Publishing top papers is not easy, but we just need to convince a few reviewers.
Building top products is much harder, as we need to convince millions if not billions of users.
For my projects that have turned into both products and papers I am always much more excited about the former, and I care less about the latter as time moves on.

In summary, know what really matters, focus on these, and spend minimally possible effort for everything else (and have the gut to drop balls on these when necessary).

For undergrad/MS students

[Disclaimer: I skipped most of my classes since high school, because I found learning by myself much more fun and efficient.]

Focus on courses that can improve your math and coding, the foundation which can help you learn everything else.
Other than that, just choose courses you find interesting, subject to the school requirements.

For PhD students

As a PhD student, people care only about your publications, not the courses you have taken, including your GPA.
Thus, I would suggest taking courses in the following prioritized order to maximize fun and minimize pain:

. Necessity that is mandatory to fulfill your course requirements. Just spend the minimally possible efforts to pass the grades.

. Utility that you think can help your research. I recommend spending more time on these, as you will have to learn them one way or another.

. Fun – those topics that you find interesting and may provide inspirations for your longer term research.

In any case, focus on learning, not earning grades.

For those of you who need my approval for course selection: please come up with a list and we can start discussion from there. I believe it is better for your education if these decisions are made by yourself.

See here for the related post about how to do a rebuttal.

Again, this is mostly for SIGGRAPH, but likely applicable for other publication venues.

My answer is absolutely yes, for a very simple reason: the amount of time and efforts you spend on rebuttal will be a small percentage of what you have spent in submitting the paper (4 days versus months if not years). Thus, you have everything to gain, and little to lose.

More reasons:

. Review is a highly stochastic and unpredictable process, and nobody knows what is going to happen. I have seen papers with strong rating (e.g. > 4) rejected, and weak rating (e.g. < 2.8) accepted. (And yes, both are mine. And I was told the latter is a SIGGRAPH record.) . Not submitting a rebuttal is usually perceived by reviewers as a (negative) sign that authors agree with their (negative) comments. . Rebuttal is a good practice for both research method and emotion control, especially for students, junior researchers, and myself. . Show you get balls. As a reviewer I admire authors who can manage to come up with strong rebuttal even for a paper with low ratings.

As someone spending the first decade of career in the industry and the second in the academia, I am naturally very positive towards students taking internships. I can see several main benefits:

. Learning; especially for practical stuff that is very hard or impossible to obtain in school. One of the key lessons I got from NVIDIA is that “ideas that work in the academia usually do not work in practice”.

. Networking; you can know more people, many of who may turn out to be good mentors, friends, or referrals/references for your future career development.

. Experience; I particularly encourage internships in another country, culture, or continent. People with broader life experiences tend to be smarter, happier, more tolerant, and more creative. Or simply put, better.

However, not every internship is beneficial. I usually only recommend opportunities that (1) are with top companies/groups/individuals in our disciplines, such as MSR, NVIDIA, Adobe, Autodesk, and Disney for graphics or HCI, (2) provide projects that fit your research direction, and (3) allow my participation and (better) can be continued after the end of the internship (these will benefit everyone involved). So, I will not recommend internships with non-top hosts, coding/implementation projects involving little research, or secret topics that cannot lead to publications.

The main point of internship is for your learning, not for making money, which is the purpose of work, which you will have plenty opportunities to practice after you graduate. The distinction between work and internship is very important, and I will not allow part time jobs during your study.

About qualification: because I only work with top people, I can recommend only students whom I consider qualified; otherwise the student will either not get the internship, or (worse) not perform up to the expectation, which benefits nobody. So, just like my general principle of being the best, make sure you perform well with me, and having some SIGGRAPH/CHI papers definitely cannot hurt.
🙂

I am explaining this in the context of research/academic job hunting, but similar principles can be applied to other situations.

The effectiveness E of a particular individual as your reference can be expressed by the following equation:
E = wcQ
, where w is the weight of the individual, c the strength of the connection, and Q the quality of the recommendation.

In particular:

. w is the weight of that individual in the particular field you are applying your job for. A nobody has a weight with absolute value close to 0, while a bigwig has weight with absolutely value close to 1. Note the mention of absolute value; the weight can be positive as well as negative. (Think about having Charles Darwin as reference for a scientific versus theological post.)

. c is the strength of connection between you and that individual, a real number between 0 (e.g. you do not really know each other) and 1 (e.g. the two of you fought in the same foxhole during WWII).

. Q is the quality of recommendation, a real number between -1 (e.g. you did not realize you actually pissed off that guy) and 1 (e.g. you wrote a 1000+ citation paper with your PhD adviser).

Your job is to identify individuals who can give you sufficiently large E values. Thus, do not ask people who are not very successful (near 0 w) or (worse) are archenemies with the institution you are applying for (negative w), who barely know you (weak c), or who are too busy (near 0 Q) or too pissed (negative Q) to write good recommendation.

You want a reasonable number of large positive E values.
The definition of *reasonable number* is application dependent (pun intended), but I would say 5 is about right for a research/academic job, 3 will be a bit too weak, and you probably do not need more than 7 unless you are applying for a senior position.
Also, make sure your E values are all sufficiently large and positive; having a bunch of weak E will not help, and can give the impression that you have difficulty finding good references.

Last but not least, ask and obtain consensus from people before listing them as your references. It can be very impolite, and downright dangerous, if you do not do so.

If you feel these are all common senses, you will be surprised by how many people commit the very basic mistakes.

A more comprehensive post can be found here.

Main point

Spend most (if not all) the time networking. Reason: meeting with people is the main feature of a conference, and the only thing that is hard to manage otherwise.

Every other conference activity should facilitate networking.
For example, I listen in technical paper sessions not because I have to (it is more efficient for me to read the papers at home); rather, I just want to compliment and chat with the speakers after their presentations.
I also like to see stuff far away from what I usually do, like animations and artistic sessions. I have met some very interesting people there, and got some useful inspirations for my work.

Below are more detailed points.

What (and what not) to say

A simple rule of thumb is to say only positive things. It can hardly go wrong. Humans like to be complimented, and I have never failed to hook up conversations with authors by saying how much I like their work. If you want to engage the conversation further, ask open-end high-level questions, like potential future works. Questions about details tend to make authors retreating inwards for answers rather than outwards towards you.

Demography

It is part of human nature for older people to like to talk to younger people, males to like to talk to females, and mortals to like to talk to nice-looking or charismatic folks. So, if you are a minority relative to the aggregate conference demography, e.g. nice-looking young female attending a computer science conference (which tends to be attended by people who are not very nice-looking, not very young, and not exactly female), you will naturally get more attention. Use this to your advantage. See that 70 year old Turing award winner standing in the buffet line who seems quite intimidating? Walk to him and ask about advices, and you will be surprised by how nice and talkative he turns out to be.

Conference size

If the conference is small, like no more than a few hundred people, try to talk to everyone. Most conferences belong to this category. Personally, I like these small venues because they feel kind of cozy.

If the conference is large, like SIGGRAPH, then it depends on your demography (see above). I usually try catching up with everyone I know first, and if time permits, knowing new folks that I find interesting.
Below is a rough sketch of my algorithm:

function UponBumpingInto(Guy guy)

if(I am already done talking to guy)
  do everything to avoid another long talk without being impolite;
else if(I already know guy or guy is important)
  chat with him/her;
else if(guy seems funky and I am not in a rush)
  chat with him/her;
else
  appear to be rushing to a session or occupied by an important phone message;
endif