A capital crime for computer science is manual repetition of uninteresting tasks. You will be happier and more productive by proper automation, which, coincidentally, is a main job for computer scientists.
For example, instead of sitting up all night tuning parameters of an experiment, you can write a script to try over a million settings over night while you go home sleep or have a fun time in Lan Kwai Fong.
I stumbled upon this article about group brainstorming today.
It echoed well with my own personal experiences and my general take that meetings are almost always completely useless for research/creative works.
I do meetings only when absolutely necessary, such as resolving major confusions or conflicts among multiple team members, evaluating live demonstrations of a UI design, and interviewing (i.e. reading) people.
Some managers and administrators like meetings. Fight them with all your power. Do not let less intelligent people waste your time or reduce your effectiveness.
My PhD adviser once told me that the most difficult part for graduation is scheduling the oral defense.
I thought he was joking, but realized he really meant it after doing it myself. It is basically a NP-hard, if not non-computable, problem.
I consider this as part of the ritual for graduation, so I will let the candidate schedule his/her own oral defense. People who cannot even get this done do not deserve to graduate.
I never understand the rationale for hundreds-page thesis or hours-long oral defenses (PhD or other research degrees); it is probably residue from some ancient practices. But I think it is a big waste of time to write or read (or print, for heaven’s sake).
Here is my proposed thesis format:
Part 1: a concise summary of what the thesis is about, and why people should care about it.
Part 2: simply staple (via Latex, not physical papers) the relevant publications together to explain how it is done.
And here is the corresponding format for oral defense:
Part 1: a (sub) 5 minute elevator pitch telling people what the thesis is about and why they should care about it. There is a short break after this stage. The candidate fails if (s)he cannot convince the audience why they should continue to listen.
Part 2: a (sub) 25 minute presentation of more details, which can simply be a re-compilation of past conference talks. What follows is a usual break for committee discussion.
If the candidate does not have solid publications, (s)he should not be able to graduate.
If (s)he does, it should probably take at most a day to prepare the thesis and oral defense, on top of the existing materials.
The committee members can just spend as much time reading the published conference/journal papers instead of bloated mumbo jumbo in hundreds of pages.
If the candidate knows what (s)he has been doing, (s)he should be able to articulate a clear elevator pitch.
Otherwise, (s)he does not, and probably should come back to think and work more.
The committee members can quick see the quality of the research work instead of having to sit through hours-long slug about some technical details.
I plan to implement these for my internal students. And please, just send me the pdf file of your thesis. Spare the trees.
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).
🙂
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.
I stumbled upon these advices on advising by David Patterson (here) and Jeff Ullman (here) today. I found both insanely useful, especially after having a few years of advising experiences. The advices differ in the way that Patterson is mainly on systems and Ullman mainly on theory. But they also share similarities such as the importance of identifying problems and collaborative work.
(I would really love to hear from someone in graphics and HCI, fields with more emphasis on human side applications. I am thinking about asking my former school advisers/professors to write such articles.)
I reflected upon my (unusual) style of individual work and asynchronous communication. This has been quite effective so far, but I never stop thinking it could go wrong, at least for some students. So what I did is to make sure there is always at least one co-adviser who can help with the normal human side of needs, like in person meetings and emotional support.
Exposure to industry labs or even startups, fortunately, should be the benefit of working with me, given where I came from and whom I know.
I encourage all my past, current, and future students to read these articles, and let me know if you have any comments.
I am picking up HCI as it is becoming more relevant to my teaching and research. Here is a log of what I have found useful. As work in progress things are going to be in a flux. If you have suggestions I would love to hear.
PS: Back in grad school my PhD adviser once commented that UI design is my Achilles heel. 🙂
The design of everyday things by Donald Norman is an old text but has aged quite well. The thing I like most about the book is that it provides many highly intuitive examples and counter examples to illustrate many of the practical design issues.
I learned about user studies from measuring the user experience by Tullis and Albert. It is pretty comprehensive, but for detailed math/theory you will need to look up elsewhere.
The coursera course by Scott Klemmer covers several main aspects of HCI and is fun to participate. I quickly went through it off season within a few days so I just watched the videos and did the quizzes. I plan to join the next offering and do the homework assignments (for real).
To some of my collaborators who have recent troubles with svn auto notification:
Instead of the usual spam run on my svn mail server, this time the issue seemed to come from over-zealous spam filtering. That is beyond my control, so I did a workaround.
(See below for more details if interested.)
The only difference is that you will see only yourself as the email recipient instead of everyone else on the cc list.
But this is probably a good thing as it can discourage the temptation to reply all through email.
Let me know if you still see issues.
Here is a quick guide on setup for linux. I will let you search online for other systems and more details.
. Under the “hooks” directory of your repository, there should already be a file named “post-commit.tmpl”. Copy it to a file named “post-commit”, and set x permission for ug. As the name implies, this is the file that will be automatically evoked after commit.
. There should already be a line similar to the following at the end of that post-commit file. All you need to do is to set the proper directory for commit-email.pl and append proper email list.
/usr/share/subversion/hook-scripts/commit-email.pl “$REPOS” “$REV” -s “Project Name” person1@foo.bar person2@foo.bar
. Alternatively, you can also use mailer.py in lieu of commit-email.pl. The former will give you more options while the latter is simpler. For mailer.py, use the following line instead of the commit-emai.pl line above:
/usr/share/subversion/hook-scripts/mailer/mailer.py commit “$REPOS” “$REV” “$REPOS”/hooks/mailer.conf
You also need to put a mailer.conf file under the same directory.
Below is a simple basic setup that works well for me.
[general]
# This command will be invoked with destination addresses on the command
# line, and the message piped into it.
mail_command = /usr/sbin/sendmail
[defaults]
# This is not passed to the shell, so do not use shell metacharacters.
# The command is split around whitespace, so if you want to include
# whitespace in the command, then ### something ###.
diff = /usr/bin/diff -u -L %(label_from)s -L %(label_to)s %(from)s %(to)s
# The default prefix for the Subject: header for commits.
commit_subject_prefix = Project Name
# The default To: addresses for message. One or more addresses,
# separated by whitespace (no commas).
# NOTE: If you want to use a different character for separating the
# addresses put it in front of the addresses included in square
# brackets ‘[ ]’.
to_addr = person1@foo.bar person2@foo.bar
# If this is set, then a Reply-To: will be inserted into the message.
reply_to = noreply@foo.bar
# Specify which types of repository changes mailer.py will create
# diffs for. Valid options are any combination of
# ‘add copy modify delete’, or ‘none’ to never create diffs.
# add: generates diffs for all added paths
# copy: generates diffs for all copied paths
# which were not changed after copying
# modify: generates diffs for all modified paths, including paths that were
# copied and modified afterwards (within the same commit)
# delete: generates diffs for all removed paths
generate_diffs = add copy modify
# A revision is reported on if any of its changed paths match the
# for_paths option. If only some of the changed paths of a revision
# match, this variable controls the behaviour for the non-matching
# paths. Possible values are:
#
# yes: (Default) Show in both summary and diffs.
# summary: Show the changed paths in the summary, but omit the diffs.
# no: Show nothing more than a note saying “and changes in other areas”
#
show_nonmatching_paths = yes
The mail filter appeared to be rejecting and considering as spam some automatic notifications with multiple recipients. So a quick workaround is to send out emails once at a time to individual recipients. This can be easily achieved via commit-email.pl as follows:
for person in person1@foo.bar person2@foo.bar
do
/usr/share/subversion/hook-scripts/commit-email.pl “$REPOS” “$REV” -s “Project Name” $person
done
For mailer.py, you will need separate conf files for individual recipients. This does not look very convenient to me.
You think GPA is important and spend time boosting your grades.
You think research is as deterministic and well-defined as courses.
You wait to be told what to do rather than figure out your own way.
You think you are working for your adviser rather than yourself.
Instead of work continuously, you let external factors (e.g. holiday and semester breaks) disrupt your flow.
You do not read every paper in the top venues of your fields especially during your first few years.
You try to read and understand every paper completely like textbooks.
You feel that deadline 3 months later is still far away.
You believe you are smart enough so that you do not have to work as hard as others.
Theme: Rubric. Get a free blog at WordPress.com