Why review papers?

A few days ago, in response to my complaining about all the reviewing I’ve had to do lately, an undergrad researcher friend asked me, “what’s the incentive to sign up to join PCs and review papers? it seems like a lot of (free?) labor.”

Good question! Here are some reasons why someone might sign up to review academic papers. TL;DR: you should review papers in order to: provide a crucial service to the community; see a preview of new work in your field; advocate for the kind of work you want to see more of; build a reputation; see and learn from what other reviewers say; get better at writing strong papers yourself; better understand how arbitrary acceptance and rejection decisions can be; and feel good.

Refactoring as a way to understand code

Recently, an acquaintance was complaining of a project they were working on that involved reading a mountain of “incidentally complex” code — code that wasn’t doing anything particularly interesting algorithmically, but that was nevertheless so hairy that it was difficult to understand the implications of adding even the small feature they wanted to add. After reading code non-stop for a week, they were tearing their hair out in frustration.

Some notes from SPLASH 2015

Last month, I headed to Pittsburgh for SPLASH 2015. Sadly, the trip was brief, since I had to leave the conference early to make it to a friend’s wedding, but aside from my own talk at SPLASH-I, I managed to catch several other SPLASH-I talks, chair a session at Onward!, participate in a lively panel discussion, and throw a practice talk party in my hotel room. A few themes emerged from the smattering of talks I saw at SPLASH: domain-specific languages, “end-user programming”, a blurring of the distinction between dynamic and static languages, distributed programming, and program synthesis — all topics of interest to my group at Intel Labs.