Not having to observe Western holidays is your competitive advantage. Don’t squander it.
December 23, 2013
July 26, 2013
I did not bring my laptop to SIGGRAPH this year to discourage myself from working inside the convention center or the hotel room.
Experimental results indicated that this motivated me to spend more time hanging out with people, which is supposed to be the main goal for a conference. I can easily schedule all events and meetings via my smart phone and tablet. (Even the tablet is probably not necessary, if I can address a few technical issues of my phone.)
I probably would have had to bring my laptop if I had to give any talks. None of the Android apps I know of can adequately author talk slides. If such apps eventually show up (and I expect they will), I would happily travel with only my phone in the future.
Eventually though, the phones will likely become powerful enough for me to work inside the hotel rooms (again).
July 18, 2013
Most paper committees I have served have purely electronic review processes. These are relatively easy. Those with in-person meetings (e.g. SIGGRAPH) are more challenging as they involve live human interactions in real-time.
Below are some of my personal experiences to make the process more fun and effective.
The most important and yet difficult task is to remain neutral, no matter what happens. It could be quite some experience to see your paper getting rejected and immediately you have to discuss a paper you reviewed.
I have a very simple strategy that works superbly well for me so far: I just assume all my papers are (or will be) rejected, even if they have very high ratings. (Anything could happen, and has happened before.) By assuming the worst case scenario, I can never be disappointed. I also do my best NOT to track my papers; I did not even look at the status on the spreadsheet when I am outside the room. Then it is easier for me to remain cool.
It also helps if you naturally care less.
One possibility is to not have any submission, but this is not common for people who are still productive.
Another possibility is to have enough prior papers so that you care less.
The paper chairs like to recruit more senior people not only for experiences but also for this “care less” factor.
Other things being equal, it is usually better to be positive than negative. My rule of thumb is to accept if unsure. This is better for humanity; a good paper wrongly rejected will not be read by anyone, while a bad paper wrongly accepted will likely be ignored by future research anyway. This is also better for myself; I do not want to leave a reputation for being a paper killer.
It is a lot of work to review 20-something papers. You will look bad if you do not seem to know what each paper is about, especially during the plenary sessions or breakout discussions. So make sure you put in enough efforts.
I also keep enough dark chocolate around to maintain my brain function at the end of the (long) day. (OK this is probably some lame excuses; I overdose cocoa no matter what.)
I am probably lucky (or maybe I am good at requesting papers; dunno yet) in that I usually get good assignments (high quality submission fitting my interests and expertise well), so I usually know each paper well. For those few that are outside my expertise, I just admit it to other committee members and reviewers. Nobody knows everything, so honesty is often the best policy.
Plus, I guess many of you have seen reviewers who clearly have no idea what the f*** they are talking about, so try not to be such jerks.
For those of you who think the committee members have some edges in getting their papers in, you might be disappointed; as far as I can tell, no such advantages exist, and the system has been well designed so that it is very difficult to game.
However, the committee members do have advantages in organizing the paper sessions, which is also the most fun part of the committee service in my opinion. You can influence where and when papers (including yours) go and which sessions you chair. People who do not show up might find papers (they authored or reviewed) going to a strangely titled session with a motley collection of seemingly unrelated papers, or find themselves chairing sessions that are too early for many people to wake up or too late in the last day for many people to remain behind.
June 2, 2013
Giving a good paper presentation is already hard, but at least you have 20 minutes’ worth of wiggle room. Giving a good paper fast-forward is even harder, because you have only 40 seconds. Even one tiny mistake can ruin you.
The most common mistake is trying to explain too much (I like to call it “geek’s asymmetry”). Trust me; almost nobody will care, and certainly nobody will understand, within 40 seconds and among 100+ presentations.
The fast-forward is pure advertisement with one main goal: get people read your paper and attend your talk.
On top of that, if you are really good, show what a cool and interesting guy you are. But do not even try unless you are absolute sure. (A good rule of thumb is this: are you already cool and interesting?)
Write down the script first, so that you know what you want to talk about and you can comfortably utter the sentences within the limited time frame. Practice and rehearse a sufficient number of times, especially if you lack verbal proficiency. Only design your slides after the script is in a stable condition. This is extremely important. If you do it the other way around, and I know this is what most people would do, you are making a grave mistake, because (just like what movie critics would say) you are letting the effects get in the way of the substance.
Do not force people read your slides. Use pictures and animations instead of texts to explain your points.
After having both the script and the slides, practice, until you can do it perfectly during sleep.
March 15, 2013
A recent PhD graduate whom I know well, who has been doing quite well in graphics research, just took a non-research job in a non-graphics position, among several postdoc offers from top research institutions.
The reasons he cited are numerous, but the 2 main ones are:
. He likes graphics research, but he is getting bored and tired of the SIGGRAPH game, including deadline crunch and dealing with reviewers.
. He would like to learn something new and try a different life style.
In a nutshell, I think he is burned out. I hope I have done my best to help him achieve work-life balance (I did that quite well myself, even when I was a grad student), but I guess it is just too hard for normal people to be much disciplined.
Then I realized that I probably also had some kind of burnout around my graduation. I took a non-research position as the first job, even though it was in a graphics company (NVIDIA). I also wanted to try learning new things (hardware architecture) and living a different style (engineer).
So I guess it is probably OK. People are not meant to be doing the same thing all the time. This is also why I like to try different job sectors and geographical locations.
There are two things to watch out, though, all based on my personal experiences: passion, and rust.
I have a very simple rule to choose jobs: do what you really like, and be very good at it.
Sometimes, when people get burned out, they might temporarily settle for something that they neither really like nor really be good at. But eventually, you will know if the job is not for you. I did not realize how much I like doing research until after I was not been able to spend enough time on it for about 3.5 years after my graduation.
The important thing is to get out there as quickly as possible. Otherwise, you will eventually become one of these people who are not really happy or good at their jobs but also cannot quit.
People tend to get rusty for skills that they have not practiced for a while. This is particularly so for advanced skills, like research.
So, make sure you do whatever you can to be active in research during your non-research job. Otherwise, you might not be able to come back, even if you want.
I have been trying my best to be engaged in research during my NVIDIA days. I even managed to publish a single authored graphics hardware paper. But it still took me about 2 to 3 years to get back in shape for SIGGRAPH after joining MSR. The difference between SIGGRAPH and other graphics venue is like the difference between playing professional sports and working out in a gym.
I guess SIGGRAPH is probably an extreme case, but I hope you get what I mean.
January 7, 2013
It is usually a very good idea to share the code and data along with your published papers. This will make it easier for others to reproduce and compare against your methods, which in turn can make you more popular and your papers more widely cited.
As a corollary, it could also a good idea to submit your code and data along with your paper for peer review. Reviewers tend to like your paper more if they can reproduce your results. However, there are a few things to watch for. The first, and the obvious one, is to make sure your code actually works as advertised. Another is author anonymity; for venues that mandate it you will want to make sure your code and data (just like your paper) do not contain any information that can identify the authors. If you have doubts on this, one possibility is to submit your code and data as non-anonymous materials, if the particular venues allow this (e.g. SIGGRAPH). This can reduce the risk of breaching anonymity and yet allows the committee members to back you if the need arises.
December 31, 2012
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.
November 10, 2012
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.
September 8, 2012
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.
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.)
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.
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.
July 19, 2012
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.
. 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.