Confessions of a researchaholic

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.

Goal

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?)

Design

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.

Practice

After having both the script and the slides, practice, until you can do it perfectly during sleep.

Svn is my choice for revision control. I usually use c++ to write the core components, and perl/php/csh scripts to run them. More information can be found under http://svn.liyiwei.org/public/, which contains public domain code of some of my projects.

Those are all relative toy cases.
Real deals can be found in good tech companies.

The best research software practice I have personally experienced is in the NVIDIA GPU architecture group. Strictly speaking, it is development, but there is plenty research involved due to its cutting edge nature. And it worked. Tens or even hundreds of engineers can collaborate on the c-models for multiple versions and generations of GPUs, each with staggering complexity. The products shipped and nobody lost their mind as far as I know.

PS I always believe the tremendous benefits of having at least a few years industry experience before joining the academia.

I use paper drafts to manage my research projects including everything: writing, experiments, results, and communications. Other than external storage (e.g. Dropbox or Google site) for data that does not need fine-grained revision control, I never need anything else, like meetings or emails. So far, this mechanism has worked superbly well, for my team projects as well as single authored papers.

This is one of those things that are better experienced than told, but here is a brief description of what it is like.

First of all, you need to have some idea what a research paper is like. All you see are finished and polished products. However, few, if any, research paper is written in one pass. They all went through some iterative evolution process. And here is mine.

I usually start drafting up the abstract the moment I have the idea. Do not worry if it is immature. It should be, as otherwise the idea cannot be new. Just write it down. Do not worry about grammar or anything cosmetic. Just make sure you can understand yourself later.

Gradually add more materials to that paper draft, including everything you see in published papers like introduction, literature survey, algorithm descriptions, math equations, experimental results, as well as those you might not see, such as thoughts, discussions, failed experiments, and ideas for future works. I usually keep a main part that eventually becomes published papers, as well as a blog part keeping daily progress and discussions.

I use svn/git for revision control, and Latex for document source. I structure the files so that I can simultaneously compile multiple versions from the same set of source (with different flags), such as final.pdf for final submission and draft.pdf that contains everything, including discussions among co-authors.

Because I put everything in writing, I never need to be reminded what has been done, what is yet to be done, and who is doing what. I can concurrently manage a double digit number of projects without losing my marbles. I also can collaborate with anyone anywhere without any other forms of meetings, because all discussions can be conducted through the paper draft. For example, if I see a mistake in an equation, I correct it, and put a note nearby explaining what I have done and why. The other guy, who wakes up in another time zone 8 hours later, can see exactly what has happened. Even for my UI papers, one guy can record a short video (or better, the editing history) for another guy to replay.

I have provided a didactic case, for file structure, research methodology, and the revision history.
One day I might be able to share a real project repository. Everything will naturally make sense when you start working with me (or one of my academic descendants) on real projects.

Because (borrowing a metaphor from finance) doing incremental research is like picking up nickels in front of a running steamroller.

The steamroller is driven by folks who have been publishing on a specific topic recently.

You see (incremental) opportunities to improve on their direction, like nickels on the floor.

And you feel like picking up those nickels. Why not? They are right over there.

However, the steamroller is also on its way to get to the nickels. (An obvious point, but people are surprisingly ignorant to it, especially when they are focusing on the nickels.)

So the questions you should ask are: are you fast enough to beat the steamroller to the nickels? (This depends on your competitive advantage.) And in case you just barely make it, are you tough enough to keep running in front of that steamroller at least for a while? (You have to do some tough comparisons with competing methods.)

Meanwhile, there are golden nuggets elsewhere. They are hidden and harder to find, but they are far from the steamroller and a whole bunch of other people trying to pick up nickels.

I will let you decide where you want to go. If you want to pick up nickels, fine, but I will just sit there watching you running in front of that steamroller. I prefer to be the first guy finding the golden nuggets, and when others notice me, I am already moving on to other places.