Although a significant fraction of the programming languages community works on detecting race conditions in multi-threaded software, I haven’t been able to get very excited about this. Certainly race-free programs have some nice properties, but race freedom is neither a necessary nor sufficient condition for concurrency correctness. This research area doesn’t feel to me like it is fundamental, but rather an evolutionary stage that has already worn out its welcome.
What I’d like to see — both as a developer and as a researcher — is a much more concrete link between concurrency control and program correctness. For example, in invariant-based synchronization, we specify the invariants that must hold over concurrent data structures and then use partially automated methods to derive locking solutions that guarantee that the invariants are maintained. Coarse-grained solutions are easy to find, and of course fine-grained solutions require more work. The scarcity of papers on this kind of idea has surprised me for a while now. I predict that ideas similar to invariant-based synchronization will become a popular area of research when people get over races and transactions, probably in the 2015-2020 time frame.
I attend a few computer science conferences each year, and look closely at the proceedings for another half dozen. I know how to deal with these conferences. On the other hand, the conferences that give me trouble are the next 25 or so that I’m passingly interested in, that probably each contain 1-2 papers per year that interest me, but that I don’t have time or energy to monitor closely. Today I finally realized how to deal with these: we need a very low-traffic RSS feed for every CS conference. It should get about four items per year: the CFP, a single reminder about the deadline being near, the advance program, and the final program including abstracts and invited speakers. The ACM could easily do this for their conferences (perhaps they already do, but I couldn’t find this in the digital library anywhere), as could USENIX and IEEE. But it might be better if this were done by a third party such as DBLP. Indeed, a bit of searching turned up this tool that automatically builds a feed from DBLP, but this is of limited utility for me since DBLP seems to be overwhelmed and is missing many of the minor (and some not-so-minor) events that I’m interested in. arXiv is another possible source, and they already have a nice system of feeds, but they seem to lack any kind of good integration with the conference system, and in any case arXiv buyin from computer scientists is minimal at present.
The other day I was working at a coffee shop and overhead a conversation between a Navy officer and a high school kid who was interviewing for some sort of scholarship program. At one point the interviewer gave the student a few pieces of general advice, including a strong admonition to be more well-rounded. It struck me that I didn’t understand the value of being well rounded and the more I thought about it, the less sense it made. When I interview students for my group or faculty for my department I’m not remotely interested in their well-roundedness. In contrast, I’m looking for pointy people who are absolutely excellent in a few areas. If this means they gave Sister Carrie a miss in English class, dropped out of boy/girl scouts early, and never touched a tennis racket then great — I prefer people who manage their own priorities instead of meeting the bizarre collection of external expectations that seems to constitute well-roundedness. Does this mean I like boring people who only care about their area of focus? Of course not. The idea that I hate is well-roundedness for its own sake, or for the sake of pleasing others. I have friends who are good musicians or artists, who are highly athletic, who are deeply religious, who party pretty hard, and who are socially conscious. I love and value these qualities in them.
So what are people really saying when they say they want someone to be well-rounded? This question needs to be asked because well-roundedness is not inherently valuable — it’s clearly a proxy for one or more other qualities. My guesses are that:
- Well-rounded people are probably well socialized, and are likely to interface well with others because there are shared interests.
- Well-rounded people have a history of meeting external expectations and are likely to continue doing so.
- Well-rounded people are those who could afford the money and time that it took to become well-rounded.
- Well-rounded people probably meet a minimum level of intelligence because they were able to master, at least to a basic level, a diverse collection of skills.
Taken together, these qualities seem to identify people who will make wonderful cogs in the machine.
I make it into the Uinta mountain range less than once a year, on average, even though its near end is only an hour from SLC. Yesterday, taking advantage of the early snowfall, Bill and I snowshoed up the Norway Flats trail a few miles east of Kamas, UT. Actually we didn’t even put on the snowshoes for most of the way up since a snowmobile had been up the trail, but on the way back we dropped off the trail and that was more interesting. It was good to get outside, and it was also good we went on Saturday since here’s my back patio tonight:
Earlier this fall while visiting Zion NP I did the Angel’s Landing hike with friends. This route climbs the spine of a sandstone fin that sticks out into the middle of Zion Canyon, with thousand-foot drops on both sides. This video captures the feel, though the use of a wide-angle lens makes it look worse than it really is.
There are a few unnerving spots on this route. However, the subjective hazard is quite low since chains have been rigged any place where a single misstep would lead to a big fall. Routes I’ve done like Borah Peak and the traverse of Devil’s Castle have much thornier combinations of exposure and easy climbing moves, and of course have no chains. The worst thing about the hike was the presence of a large number of children — some of them looked no more than three and it really freaked me out watching them negotiate the exposed spots.
I’m a happy Ubuntu user and usually upgrade to the latest version within a month or two of its being released. However, things seem to go better when I reinstall the system from scratch (leaving /home untouched of course) rather than upgrading in place. The only annoying thing about this plan is that I then keep tripping across missing packages that I use every day, that are not part of the default package set. My home machine running Ubuntu 10.10 contains 358 packages not part of the default package set, but when I looked at these it turned out that most of them are transitive dependencies. So I wrote a little Perl script that computes the minimal set of packages I need to install to get all the rest and it is just 49:
acroread apt-rdepends bibclean bzr cutils ddd debtree dejagnu delta emacs flex git-core gm-notify googleearth googleearth-package gperf hamster-applet htop imageshack-uploader indent inkscape kvm-pxe latex2html latexdiff libelf-dev libjpeg62-dev liblablgtk2-ocaml liblockfile-simple-perl libpng12-dev libsdl1.2-dev libsys-cpu-perl ocaml ocaml-base ocaml-base-nox openssh-server pdfchain pdfjam pdfsam pdfshuffler python-dev python-matplotlib shutter sqlite3 sun-java6-jdk texlive-math-extra tofrodos ubuntu-restricted-extras valgrind virtualbox-3.2
Of course, package names sometimes change across releases so this list won’t carry over 100%, but even so it should make my next upgrade a bit easier. Here’s the script, which requires apt-cache to be installed and assumes that the CWD contains the files packages_orig.txt and packages_custom.txt that were produced using dpkg -l on a fresh and customized install, respectively.
This is a quick followup to this post from the other day. Here I’m going to list a few of the strategies I’ve developed for keeping my job from driving me crazy.
- Find places to work: home, the library, the coffee shop, whatever. Although new professors are often able to get work done in the office, it only takes a few years before so many people know where you can be found that it becomes impossible to get uninterrupted work time. Closing the door is of little help.
- Say “no” to things. Many of us are abysmally poor at this, but eventually it becomes a necessity. Figuring out when to say “yes” vs. “no” is hard.
- Don’t be afraid to do a bad job on things. It feels awful to submit a poorly edited paper or proposal, but it is simply impossible to be a perfectionist when there are 30 things to do and a week in which to do them.
- Find ways to keep teaching fun. Teaching the same course over and over rapidly becomes boring. Ripping out and replacing lame lectures, coming up with new and exciting programming assignments, and offering interesting extra-credit work are all fun. My favorite kind of extra-credit work is a contest where students need to create the fastest or smallest code for some task — this really brings out the best in the students.
- Stay in shape. I spent a few years letting work destroy my exercise schedule and it was a terrible idea, I ended up 25 pounds overweight and with high blood pressure. I now run or hike 45 minutes a day regardless of how crappy things are at work.
- Keep doing technical projects. During my first two years or so as a professor I wrote too many proposals and spent too much time teaching and otherwise interacting with students. I was totally miserable until I realized that I needed to keep a couple of technical projects to work on myself. It’s not even hard figuring out which ones: there are always plenty of ideas that are too speculative (read: stupid) to hand off to a student, but are still great fun to work on.
- Stop caring about individual papers and proposals. It took a while for me to learn to get over rejections quickly, and to start to see the research process as sort of a broad, fuzzy, long-term effort with very vague ups and downs, rather than as a sequence of individual efforts punctuated by total victories and abject failures.
- Stop caring too much about tenure and just get work done. Obviously this has to be done in moderation, but it’s critical: the tenure incentives (lots of pubs, lots of $$, lots of service, high teaching evaluations) are simply too screwed up to take seriously.
Partially in response to Matt and Daniel‘s posts, I wanted to list a few things I like about being a professor:
- It’s a good match for my short attention span. If I get interested in something new, I can drop everything and work on it for a while. When I get tired of a project, I can just drop it (subject to constraints imposed by students and ongoing grants).
- As long as I basically do my job, nobody can tell me what to do, or would even think of trying to.
- There are few secrets. Within certain broad limits, I can tell anyone about anything I’m working on, release anything I want as open source code, and blog about whatever I like.
- I can be annoying, for example by airing dissenting opinions or pointing out flaws in popular systems. These are harder to do when my company has to maintain good relations with customers and otherwise keep making money.
- Writing papers is at the core of the job, and I enjoy doing this.
- Basically I’m being paid to be smart and to know a lot of stuff, how great is that?
- Dealing with students, both in courses and in the advisor/advisee relationship, is fun.
- I can work on things that nobody would pay me to do, if I think they advance the field or serve the greater good.
Of course it’s not all roses. Here are some things I dislike:
- The capriciousness of the peer review system is tiresome.
- I’m constantly spread too thin, and do a bad job at things because of this.
- Dealing with students is not fun when they are apathetic, entitled, dishonest, or inept.
- The incentives in the research funding system are screwed up.
- Sometimes I have to go to meetings that bore me.
- I end up spending quite a bit of time being an administrator and manager, and I’m not good at these things.
- Pre-tenure, the incentives are setup to strongly reward work that has a reliable, short-term payoff, which is precisely not what professors should be working on.
This is a depressing paper. The study shows that:
92% of peer reviewers deteriorated during 14 years of study in the quality and usefulness of their reviews (as judged by editors at the time of decision)
The quality of reviews that I write has definitely decreased over the 12 or so years that I’ve been doing it. The main factor is time: I’m far busier than I used to be and I’m asked to review many more papers, grant proposals, etc. There is just not enough time anymore to write a pages-long discussion of the pros and cons of a paper. Ennui is also a factor: there are certain classes of bad paper that I’ve seen so many times that I can’t be bothered to write a detailed description of why it’s bad. Additionally, senior people often write bad reviews because they farm them out to very inexperienced students, postdocs, etc. and then fail to rewrite the review themselves (for some reason, students often write the harshest reviews). Another factor is that as people become more senior, they can start to lose touch with the technical details.
A reasonable response to this trend is to ensure that younger researchers make up a significant fraction of review committees. I deliberately did this the last time I formed a program committee. This has the additional benefit of giving younger researchers experience and visibility that they require at early career stages.
Tonight I wrote this in a paper review:
The results section of this paper contains what is probably the most elementary and most annoying flaw that could possibly plague a computer systems paper. All of the numbers are relative and we’re never told the absolute values. It’s great that you can achieve a 30% reduction in overhead, but it matters whether this is 30% of 0.1% or 30% of 10000%. I have to recommend against acceptance of a paper that does this.