Carriers are not ready for tablets

This week I spent at least two hours on the phone trying to convince both AT&T and Verizon to give me online access to accounts I set up for tablets that I am testing -- the Samsung Galaxy Tab (AT&T) and Motorola Xoom (Verizon). They are both great devices; I like the Galaxy Tab's form factor (like a paperback book) and the Xoom is incredibly fast. But it is clear that the wireless carriers have no idea how to incorporate these devices into their billing and customer service ecosystem. It was such a painful and frustrating experience that I wonder how the cellular carriers expect to leverage these devices as more tablets come onto the market.

First, my story with AT&T. I bought the Galaxy Tab a few months ago which came with an AT&T SIM card pre-installed. When you boot the device for the first time, there's a widget which takes you to a registration page, which I filled out to activate the tablet on AT&T's network. Since then I have not received a bill (to my knowledge) for the usage, and couldn't remember whatever password I might have used to set up the device. Nothing on AT&T's website seemed to offer any help, as it is completely oriented towards phones.

Finally, I gave up and called AT&T to re-register the Tab manually. The first customer service rep had no idea how to do this. They kept asking for the phone number, which the device does not have (at least when you enter the Settings menu it lists the phone number as "unknown"). Given that I had not received any bills I suspected the Tab was never registered, so we had to look it up by IMEI number. The rep could not pull up any account information. She ended up transferring me to technical support at Samsung, of all places. The Samsung rep was very friendly but couldn't help with this problem, either -- it seemed to be an AT&T issue (and I agree). I ended up having to call AT&T back, and went through the same painful process of explaining what my problem was. This rep ended up transferring me over to a different sales rep who tried to help me set up the account from scratch.

This is when things started to go downhill. All I wanted as an unlimited (or as close as possible) data plan for the Galaxy Tab. I could see online that AT&T has a 2GB/month data plan for tablets but the rep kept telling me that "their internal systems don't necessarily show what is on the website." (First warning sign there.) Eventually he managed to pull up the right plan but couldn't seem to figure out how to add a Galaxy Tab -- the device wasn't showing up in his menus. It sounded like he had never activated a tablet before. After around 20 minutes on hold he managed to figure it out, so I think I finally have the Galaxy Tab set up for data access. I was promised that I would get an email from AT&T confirming the new account, but it never arrived. So I guess I am going to have to call them back. I am dreading this.

Verizon was almost as bad. Like the Tab, I had set up the Xoom using the registration app on the tablet itself. I had made a note of the username used to set up the account, but not the password. Verizon's website offers no ability to request a new password except via SMS to the device -- and the Xoom doesn't receive SMS messages, since it's not a phone. The only way to request a new password is to spend around 45 minutes on the phone with various Verizon reps with the result being that a new password is being sent to me by postal mail in five business days. (What is this, the nineteenth century?) Of course, since I moved recently, my mailing address on file with Verizon was incorrect. Fortunately, the service rep allowed me to change the postal address over the phone -- meaning that they trust me enough to let me change my mailing address, not not enough to reset my online account password. This makes absolutely no sense and seems designed to drive users away.

The lesson here is that the wireless carriers have no clue how to incorporate tablets. They are treating them like phones, which they aren't.

Thinking back on 8 years in Boston

Tomorrow I will be packing up and moving from Boston to Seattle with my family. I thought now would be a good time to reflect on living in Boston as a city and recall some of my best memories here.

I've never lived in Seattle, though have been there many times -- it seems like a wonderful city, full of funky crazy people and absolutely beautiful geography. I'm not terribly excited about the rainy weather, though something tells me it can't be any worse than the Boston winters, when I always feel cooped up. I really miss getting out to go hiking with the dog or mountain biking during the winter months in New England -- and now that I have a kid it's especially hard to get out when it's well below freezing outside (he has a lot lower tolerance for the winter weather than I do). Rain I can deal with; negative 20 wind chills and a foot and a half of snow are something different altogether.

On finishing grad school at Berkeley in 2002, I had a few faculty job offers, and my wife was looking for residency programs in psychiatry. Our decision came down to two cities: Boston, where I had an offer at Harvard, and Pittsburgh, where I had an offer at CMU. I had lived in Boston for a while during college, so I knew I liked the city. But CMU was a very tempting offer, being a much more highly-ranked CS program than Harvard. My wife and I visited Pittsburgh a couple of times and actually liked it a lot: it was a very friendly place, and the CMU folks went all out to show us a good time. At one point we actually made the decision to move to Pittsburgh but decided to sleep on it. The next day we had to ourselves, without anyone showing us around. The only Mexican place that served "fish tacos" appeared to be Van De Kamp's fish sticks on a tortilla. I could not find a music store that allowed you to browse the CDs without an attendant unlocking a glass case to let you inside. We tried to find a decent shopping mall, hoping they would have a good record store, but found ourselves in the mall where the movie Dawn of the Dead was filmed -- I did not make it more than three paces beyond the door before we realized it was a terrible mistake. I'm sorry, Pittsburgh might be a wonderful city for some people, but it was not for us.

Monroeville Mall on a typical Sunday afternoon.

So we moved to Boston in 2003. We drove across the country in my little beat-up two-door Ford, stopped at places like Moab and St. Louis and Nashville, a little like On the Road in reverse. We arrived on a hot, sticky summer day in a thunderstorm and moved into an apartment on Dana Street in Cambridge, not far from Harvard Square. Almost immediately we felt like outsiders. Boston is a very old city, and it shows -- the old brick buildings around Harvard, the beat-up sidewalks, everything dripping with history and significance. Paul Revere. George Washington. Boston Common. Old Granary Burial Ground. The feeling was so different than the newness that is so pervasive in California. It took some getting used to.

These gravestones have been here for a while. (From http://www.flickr.com/photos/harvardavenue/66097831/)

That first summer was one of the most exciting in Red Sox history. I had never paid attention to baseball before, but it soon became clear that if I wasn't conversant in Curt Schilling or Manny Ramirez I was going to be left out of a lot of conversations. Like a lot of people in Boston, I got caught up in the excitement of the 2003 postseason when the Sox were narrowly beat by the Yankees for the ALCS title. The next year was even more exciting, in that the Sox went on to win the World Series for the first time in 86 years. The whole city went totally apeshit. For so many people living here, it was like a moment of rapture that they never believed would actually happen, the culmination of a lifetime of inferiority to cities like New York. I feel sad for some long-time Bostonians who now have no excuse to be cynical about their station in life.

People were just a little excited. (From http://www.flickr.com/photos/eandjsfilmcrew/412103968/)

Not long after we moved to Boston they finally banned smoking in bars and restaurants (which we'd been used to in California) and actually allowed alcohol sales on Sundays. It was as if the city were modernizing before our eyes. It would take another six years for Cambridge to allow outdoor dining at restaurants, which is still encumbered with backwards vestiges of the Puritans (you can only have a drink while sitting outside if you also order food).

Going out in Boston was a bit more a dressy, formal affair than we were used to in Berkeley. At all but the very highest end restaurants in San Francisco, jeans and a t-shirt were acceptable attire; not so in Boston. On the positive side, Boston has a great foodie scene. At first we were totally lost trying to find good places to eat; Zagat's is useless and Yelp simply reflects the lowest common denominator. At first we were convinced that people in Boston had no idea what real, good Mexican food was -- those greasy platters of "enchiladas" covered in melted cheese that are so popular at hellholes like Casa Romero are not it. Then we discovered Chowhound, and got turned on to a whole world of hole-in-the-wall places serving authentic Mexican and Salvadorean and Sichuan and Cambodian. Unlike Berkeley, where you can swing a dead cat and hit three burrito joints and a place with out-of-this-world sushi, in Boston it takes a bit more digging, but there is great food here.

Some of my best memories of living in Boston...

Walking my dog, Juneau, to work at Harvard every day, stopping at the coffee shop on the way, and taking her to the dog park on the way home for an hour or so of play time with the other dogs.

Juneau would occasionally help me reviewing papers, too.

Sitting outside on a warm summer evening, firing up the grill, having friends over for dinner and drinks until late.

Every single fall, feeling the first day of cold air and getting excited for the leaves to start changing.

This image has not been enhanced.

Riding my bike along the banks of the Charles River, whizzing by rollerbladers and clueless tourists walking four abreast in the middle of a bike path.

The morning after a big snowstorm, seeing the world transformed and noticing how quiet everything was with the snow on the ground.

Shoveling is always fun too.

Late nights out in Boston Chinatown with Gu, drinking beer and eating Korean food.

Watching the sun rise out of the window of Mount Auburn hospital on a hot July day a couple of hours before my son was born.

I was a dad not long after this picture was taken.

Running a successful program committee

Yesterday we held the program committee meeting for the 13th Workshop on Hot Topics in Operating Systems (HotOS), for which I am serving as the program chair. This is the premier workshop in the OS community and focuses on short (five page) position papers meant to bring out exciting new research directions for the field. In some years it has been more exciting than others. What tends to happen is that people send five-page versions of an SOSP submission they are working on, which (in my opinion) is not the best use of this venue. When HotOS becomes an SOSP preview I think it misses an important opportunity to discuss new and crazy ideas that would not make it into a regular conference.

We accepted 33 out of 133 submissions. The number of accepted papers is a bit higher in previous years because I wanted to be more inclusive, but also recognized that we could fit more presentations in at the workshop when you don't have 25-minute talk slots. There is no reason a 5-page paper needs a 25-minute talk, and I think it goes against the idea of the workshop to turn it into a conventional conference.

This was, by far, the best program committee experience I ever had, and I was reflecting on some of the things that made it so successful.

I've been on a lot of program committees, and sometimes they can be a very painful experience. Imagine a dozen (or more) people crammed into a room, piles of paper and empty coffee cups, staring at laptops, arguing about papers for 9 or 10 hours. Whether a PC meeting goes well seems to be the result of many factors...

Pick the best people. We had a stellar program committee and I knew going in that everyone was going to take the job very seriously. Everyone did a fantastic job and wrote wonderful and thoughtful reviews. These folks were invested in HotOS as a venue, were the kind of people who often submit papers to the workshop, and care deeply about the systems community as a whole. The discussion at the PC meeting itself was great, nobody seemed to get cranky, and even after 8+ hours of discussing papers there was still a lot of energy in the room. This is helped a lot by the content -- HotOS papers tend to be more "fun" and since they are so short, you can't nitpick every little detail about them.

Set expectations. I tried to be very organized and made sure that the PC knew what was expected of them, in terms of getting reviews done on time, coming to the PC meeting in person, what my philosophy was for choosing papers, and how we were going to run the discussion at the meeting. I think laying out the "rules" up front helps a lot since it keeps things running smoothly. I've blogged about this before but I think establishing some ground rules for the meeting is really useful.

Get everyone in the room. Having a face-to-face PC meeting is absolutely key to success. Everyone came to the PC meeting in person, except for one person whose family fell ill at the last minute and had to cancel, but even he phoned in for the entire meeting (I can't imagine being on the phone for more than eight hours!). I made sure the PC knew they were expected to come in person, and nailed down the meeting date very early, so everyone was able to commit. Letting some people phone in is a slippery slope. I can't count how many PC meetings I've been to that have been hampered by painful broken conference call or Skype sessions.

Use technology. We used HotCRP for managing submissions and reviews, which is by far the best conference management system out there. During the PC meeting itself, I shared a Google spreadsheet with the TPC which had the paper titles, topic area, accept/reject decision, and a one-line summary of the discussion. The summary was really helpful for remembering what we thought about a paper when revisiting it later in the day. Below is a snippet (with the paper numbers and titles blurred out). The "order" column below is the order in which the paper was discussed. This way, everyone in the PC could see the edits being made in real time and there was rarely confusion about which paper we were discussing next.

Pre-reject and pre-accept. I rejected around half of the submissions before the PC meeting and gave the PC a chance to revive any such paper for discussion (none were). I also "pre-accepted" about 10 papers that were noncontroversial; we saved discussion of these for the end of the day, since they were easy cases. We ended up discussing a total of 69 papers at the meeting, which meant we had to go at a pretty good clip.

Be definitive.  With very few exceptions, we tried to reach a clear accept/reject decision on each paper as we discussed it, and did not table any papers for later discussion. There was one case where we were hung on what to do with a paper and decided to push the discussion until the end of the day. In cases where there was disagreement, I would mark a paper as "presumed reject" or "presumed accept" and put down the name of the person who wanted to argue for the opposite outcome later. That gave us a chance to move on when there was an insurmountable debate, and it was clear that the champion (or anti-champion) of a paper would have a chance to have their say.

Take everyone out to a nice dinner afterwards. As far as I'm concerned, this was the best part of hosting the PC meeting.

What life was like before the Web

It's kind of shocking that the Web has only been around since the mid-1990s, but a lot of younger people that I work with have no idea what it was like to use the Internet before the Web. I'm not that much of an old-timer, but I thought it would be amusing to talk about the pre-HTTP Internet. A few reminisces of the good old days...

• Everything was text-based;
• There was (almost) no spam;
• There was no such thing as a search engine;
• You did everything using these crappy UNIX text-based command-line tools.

I first started using the Internet back in high school, around 1990, on an IBM RT UNIX system connected via dialup from school. Back then, there were three main uses of the Internet: email, USENET, and FTP. Email was not very common but some universities had it, and by the time I started college in 1992, you automatically got an email address as an undergraduate.

USENET

USENET was a huge distributed newsgroup system. It was based on peer-to-peer file exchange well before we called it that. There were thousands of newsgroups on topics ranging from the C programming language to the rock band Rush. Yes, it still exists; I think it's largely overrun with spam and warez these days, and I haven't looked at it in years. At the time, spam was almost unheard of so newsgroup discussions tended to stay on-topic. I was the moderator for comp.os.linux.announce for a while, which meant that every announcement to the Linux community (like a new kernel release or software package port) came to my inbox for approval before I posted it to the world.

At some point I want to write a book about USENET culture circa 1992. It was a very interesting place. Groups like talk.bizarre were frequented by the likes of Roger David Carrasso (who pulled off some of the best trolls imaginable); Kibo (founder of alt.religion.kibology); and who can forget the utterly brilliant and bizarre stories by RICHH?

I was a member of the "inner circle" for a group called alt.fan.warlord, which was centered on making fun of ridiculous signatures at the end of USENET posts, like this:

     Paul Tomblin, Head             _            _   ____
     Automated Test Tools Team     | |          | | |  __|   ___._`.*.'_._
    _______________   ______   ____| |________  | |_| |__   +  * .o   u.* `
   /  ________  _  \ |  __  | /  ________  _  \ |  ______|  . ' ' |\^/|  `.
   | |  | |  / / | | | |  | | | | |  |  / / | | | | | |            \V/
   | |__| | / /__| |_| |  | | | |_|  | / /__| |_| | | |            /_\
   \ _____/ \__________|  |_|  \___|_| \__________| |_|       === _/ \_ ===
   //
   \\____   Phone: (613) 723-6500x8018      Mail: Gandalf Data Limited
   /  _  \  Fax:   Don't know it yet              130 Colonnade Road South
   | |_| |  Email: ptomblin@gandalf.ca            Nepean, Ontario
   \_____/   or    ab401@freenet.carleton.ca      K2E 7J5 CANADA

There was a group called alt.hackers that was a moderated group with no moderator. In order to post you needed to figure out how to circumvent the moderation mechanism (which was simply a matter of adding an extra header line to your post).

FTP

USENET was all about discussions, although there were newsgroups where you could post binary files -- typically encoded in an ASCII format like UUENCODE, and broken up into a dozen or more individual posts that you would have to manually stitch back together and decode. This became a popular way to post low-resolution porn GIFs, but was pretty much useless for anything larger than a few megabytes. A better way to download files was to use FTP, which allowed you to download (and upload) files to a remote FTP server. Of course, FTP had this totally unusable command-line interface which required you to type a bunch of commands just to get one file. This site at Colorado State helpfully explains how to use FTP, like anybody still needs to know how. A typical FTP session looked like this:

%   ftp cs.colorado.edu  
Connected to cs.colorado.edu.  
220 bruno FTP server (SunOS 4.1) ready.  
Name (cs.colorado.edu:yourlogin): anonymous  
331 Guest login ok, send ident as password.  
Password:  
230-This server is courtesy of Sun Microsystems, Inc.  
230-  
230-The data on this FTP server can be searched and accessed via WAIS, using  
230-our Essence semantic indexing system.  Users can pick up a copy of the  
230-WAIS ".src" file for accessing this service by anonymous FTP from  
230-ftp.cs.colorado.edu, in pub/cs/distribs/essence/aftp-cs-colorado-edu.src  
230-This file also describes where to get the prototype source code and a  
230-paper about this system.  
230-  
230-  
230 Guest login ok, access restrictions apply.  
ftp> cd /pub/HPSC  
250 CWD command successful.  
ftp> ls  
200 PORT command successful.  
150 ASCII data connection for /bin/ls (128.138.242.10,3133) (0 bytes).  
ElementsofAVS.ps.Z  
   . . .
execsumm_tr.ps.Z  
viShortRef.ps.Z  
226 ASCII Transfer complete.  
418 bytes received in 0.043 seconds (9.5 Kbytes/s)  
ftp> get README  
200 PORT command successful.  
150 ASCII data connection for README (128.138.242.10,3134) (2881 bytes).  
226 ASCII Transfer complete.  
local: README remote: README  
2939 bytes received in 0.066 seconds (43 Kbytes/s)  
ftp> bye  
221 Goodbye.  

All this just to download a single README file from the site.

In order to use FTP, you needed to know what FTP sites were out there and manually poke around each one of them to see what files they seemed to host, using "cd" and "ls" commands in the crappy command-line client. There was no such thing as a search engine. So, people in the FTP community made this giant "master list" of every FTP site out there and a short (one-line) summary of what the side had, e.g., "Linux, UNIX utils, GIFs." This master list was mirrored on a bunch of sites but of course that was a manual process, and in effect the mirrors were often conflicting and out-of-date. These days you can find a giant list of FTP sites on the Web, of course.

The Birth of the Web

Back in 1994 or so I was doing research as an undergraduate at Cornell. At the time I was a huge USENET junkie, and from time to time I would see these funny things with "http://" in people's signatures. I had no idea what they were, but at some point saw a USENET post that explained that if you wanted to browse those funny "URL" things you needed to download something called Mosaic from an FTP site at NCSA. When you launched the Mosaic Web browser it brought up this page which was the home page for the entire World Wide Web. At some point I managed to get the original NCSA Web server running and put Cornell's CS department on the Web. Here's an archive of the Cornell Robotics and Vision Lab web page that I made back around 1995.

Not long after this a startup from Stanford called Yahoo created a (manual) index of every web page -- still not quite searchable, but at least you could find things. I remember using the original Google when it was hosted at Stanford and had a whopping "25 million pages" indexed.

Does Google do "research"?

I've been asked a lot by folks recently about whether the work I'm doing now at Google is "research" and whether one can really have a "research career" at Google. This has also led to a lot of interesting discussions about what the role of research is in an industrial setting. TL;DR -- yes, Google does research, but not like any other company I know.

Here's my personal take on what "research" means at Google. (Don't take this as any official statement -- and I'm sure not everyone at Google would agree with this!)

They don't give us lab coats like this, though I wish they did.

The conventional model for industrial research is to set up a lab populated entirely by PhDs, whose job is mostly to write papers, and (in the best case) inform the five-to-ten year roadmap for the company. Usually the "research lab" is a separate entity from the product side of the company, and may even be physically remote.

Under this model, it can be difficult to get anything you build into production. I have a lot of friends and colleagues at places like Microsoft Research and Intel Labs, and they readily admit that "technology transfer" is not always easy. Of course, it's not their job to build real systems -- it's primarily to build prototypes, write papers about those prototypes, and then move on to the next big thing. Sometimes, rarely, a research project will mature to the point where it gets picked up by the product side of the company, but this is the exception rather than the norm. It's like throwing ping pong balls at a mountain -- it takes a long time to make a dent.

But these labs aren't supposed to be writing code that gets picked up directly by products -- it's about informing the long-term strategic direction. And a lot of great things can come out of that model. I'm not knocking it -- I spent a year at Intel Research Berkeley before joining Harvard, so I have some experience with this style of industrial research.

From what I can tell, Google takes a very different approach to research. We don't have a separate "research lab." Instead, research is distributed throughout the many engineering efforts within the company. Most of the PhDs at Google (myself included) have the job title "software engineer," and there's generally no special distinction between the kinds of work done by people with PhDs versus those without. Rather than forking advanced projects off as a separate “research” activity, much of the research happens in the course of building Google’s core systems. Because of the sheer scales at which Google operates, a lot of what we do involves research even if we don't always call it that.

There is also an entity called Google Research, which is not a separate physical lab, but rather a distributed set of teams working in areas such as machine learning, information retrieval, natural language processing, algorithms, and so forth. It's my understanding that even Google Research builds and deploys real systems, like Google’s automatic language translation and voice recognition platforms.

(Update 23-Jan-2011: Someone pointed out that Google also has a "Quantitative Analyst" job role. These folks work closely with teams in engineering and research to analyze massive data sets, build models, and so forth -- a lot of this work results in research publications as well.)

I like the Google model a lot, since it keeps research and engineering tightly integrated, and keeps us honest. But there are some tradeoffs. Some of the most common questions I've fielded lately include:

Can you publish papers at Google? Sure. Google publishes hundreds of research papers a year. (Some more details here.)You can even sit on program committees, give talks, attend conferences, all that. But this is not your main job, so it's important to make sure that the research outreach isn't interfering with your ability to do get "real" work done. It's also true that Google teams are sometimes too busy to spend much time pushing out papers, even when the work is eminently publishable.

Can you do long-term crazy beard-scratching pie-in-the-sky research at Google? Maybe. Google does some crazy stuff, like developing self-driving cars. If you wanted to come to Google and start an effort to, say, reinvent the Internet, you'd have to work pretty hard to convince people that it could be done and makes sense for the company. Fortunately, in my area of systems and networking, I don't need to look that far out to find really juicy problems to work on.

Do you have to -- gulp -- maintain your code? And write unit tests? And documentation? And fix bugs? Oh yes. All of that and more. And I love it. Nothing gets me going more than adding a feature or fixing a bug in my code when I know that it will affect millions of people. Yes, there is overhead involved in building real production systems. But knowing that the systems I build will have immediate impact is a huge motivator. So, it's a tradeoff.

But doesn't it bother you that you don't have a fancy title like "distinguished scientist" and get your own office? I thought it would bug me, but I'm actually quite proud to be a lowly software engineer. I love the open desk seating, and I'm way more productive in that setting. It's also been quite humbling to work side by side with these hotshot developers who are only a couple of years out of college and know way more than I do about programming.

I will be frank that Google doesn't always do the best job reaching out to folks with PhDs or coming from an academic background. When I interviewed (both in 2002 and in 2010), I didn't get a good sense of what I could contribute at Google. The software engineering interview can be fairly brutal: I was asked questions about things I haven't seen since I was a sophomore in college. And a lot of people you talk to will tell you (incorrectly) that "Google doesn't do research." Since I've been at Google for a few months, I have a much better picture and one of my goals is to get the company to do a better job at this. I'll try to use this blog to give some of the insider view as well.

Obligatory disclaimer: This is my personal blog. The views expressed here are mine alone and not those of my employer.

Fair Harvard

I've been reflecting on my reasons for moving to Harvard seven years ago. Although I have decided to leave academia, Harvard is really a wonderful place, and I would certainly recommend it to anyone considering an academic career. Back in 2002, I had job offers from several other (big name) universities -- including CMU -- but I chose Harvard for a whole host of reasons, and am really glad that I did. So I thought it would be good to share some of the things that I love about the place.

The campus.

http://farm2.static.flickr.com/1374/5180938910_e483062647_b_d.jpg

This is an easy one. The Harvard campus is just unbelievably beautiful. It feels like the quintessential university: old brick buildings, vines, little walking paths crisscrossing the quads. Even better is that it's not isolated: it is right in the heart of Cambridge, and as soon as you leave campus you're in the middle of Harvard Square which has tons to do. Every day I would take my dog for a walk around campus at lunchtime just soaking in the atmosphere and bumping into Korean tour groups snapping photos of the John Harvard statue.

The Computer Science building.

http://www.flickr.com/photos/grinnell/3293758260/

Maxwell Dworkin Hall is home to the Computer Science and Electrical Engineering faculties. It was built in 1999 and named for Bill Gates' and Steve Ballmer's mothers --  no joke. It's one of the best CS buildings I've been to on any university campus (and I have visited a lot). The faculty offices are huge, there are great common spaces, and the overall layout (with a central open staircase) promotes interaction. It is a great place to work.

The faculty.

http://news.harvard.edu/gazette/story/2010/03/inside-electronic-commerce/

Probably the number one reason I joined Harvard was to interact with all of the incredible faculty. The thing that struck me the most when I interviewed was that the CS faculty were an amazing bunch that really have their act together and were all doing incredibly interesting things. Although a lot of places talk about being cross-disciplinary, Harvard embraces it like no other place that I've seen. David Parkes (pictured above) and Yiling Chen work across computer science and economics; Krzysztof Gajos on the boundary of AI and HCI; Radhika Nagpal across biology, systems, and algorithms; Stephen Chong and Greg Morrisett across systems and languages; Hanspeter Pfister across graphics, systems, and scientific computing ... among many other examples. What's great about this is that the faculty are not isolated in their own little worlds -- since there is so much cross-fertilization, everyone knows a lot about what the other faculty are doing. In a smaller department this is absolutely essential.


The students.

http://photos.cs50.net/Events/CS50-Fair-2010-Hugon/

This is another easy one. I have raved about Harvard students on this blog before, but it's worth mentioning again. (One of my favorite students of all time, Rose Cao, pictured above.) Working with and teaching Harvard students has been one of the highlights of my career.  They are smart, engaged, creative, passionate about what they do. It is extremely rare to meet a student who was just "along for the ride" or trying to coast through college -- not at Harvard. They pushed me and challenged me to do better all the time. My graduate students were similarly amazing, an extremely dedicated bunch who were not afraid to take risks. Although Harvard's a smaller school, I was never for want of great grad students to work with.

The department culture.

http://picasaweb.google.com/radpicasa/peoplessr#

One thing that is hard to get right in any university setting is the overall culture and feel of the department. If it's broken, it's incredibly hard to fix. Harvard's CS department feels like a family. There's a sense of a shared mission to make the place better and everyone pulls their weight. For junior faculty, it is a really supportive environment: the senior faculty work hard to make sure that everyone has the opportunity to be successful. One of the most remarkable things is how decisions get made -- nearly always by consensus, after a lot of discussion (generally during faculty lunch meetings). There's very little "department politics" and all voices are heard. Harvard chooses to hire new faculty who will fit into this culture, so there's a really strong emphasis on retaining this structure, which is great.

The size.

http://www.flickr.com/photos/mexbox/4171583189/

One of the main reasons I came to Harvard, rather than to a much larger department, was to have impact. I've often compared being at Harvard to being at a startup (though an incredibly well-funded one) instead of, say, a huge company like IBM (or Google for that matter). Though I feel that Harvard needs to hire a few more CS faculty to attain critical mass across all areas, I really like the smaller department feel of the place. Pretty much all of the faculty can fit in a single room for a lunch meeting and have a substantive discussion. Each individual faculty member can have a tremendous amount of impact on teaching and research. So being at Harvard was a great opportunity to shape an important CS department and this is one of the things that really attracted me to the place.


The city.

http://farm4.static.flickr.com/3196/3091615359_fba3419d01_b.jpg

Finally, there is a lot to love about Cambridge and Boston. It's a beautiful city and very compact. I could walk to work every day in about 20 minutes, and along the way pass countless restaurants, bars, coffee shops, record shops, you name it. Cambridge has a great mix of "big city" and "residential" feeling to it -- it is kind of like an oversized college town. Over the years I have amassed an impressive list of places to eat and things to do around the city and it never gets old. OK, I'll admit that the weather is not always ideal, but it's probably my favorite city on the East Coast, and a lot more livable (and affordable) than New York.

What would I change?

I don't want to be too negative, but for balance I think I should mention two things that I would change about Harvard, if I had the chance. The first is that the tenure process is too damn long. If all goes according to schedule, the decision is made at the end of your seventh year, which keeps you in limbo for quite a long time, making it hard to get on with your life. On the other hand, the good thing about a long tenure clock is that you can take big risks (which I did) and have time to make course corrections if necessary. Harvard is not unique in having a long tenure clock (as I understand it, CMU's is longer!), but still long compared to the more typical four or five year clocks.

The second thing is that the CS faculty really needs to grow by a few more faculty in order to realize its full potential. I think they need to hire at least five or six new faculty to reach critical mass. As I understand it there are plans to hire over the next few years, which is good.

Looking back, I'm really glad that I went to Harvard as a new faculty member. It's hard to imagine that I would have had anywhere near as much impact had I gone somewhere else.

The Best Things about 2010

Last year I posted the Best Things About 2009, so I feel compelled to do the same this year. In what is sure to become an annual tradition, I present to you the Best Things About 2010 -- Volatile and Decentralized edition.

Best portrayed cameo appearance in a major Hollywood motion picture:

Brian Palermo's dramatic and riveting 45-second performance as myself in The Social Network. The rest of the movie is just okay, but the scene where I am teaching virtual memory to Mark Zuckerberg is one of the most compelling moments in modern cinema, right up there with Daniel Day-Lewis in the final scene of There Will Be Blood.

Best phone call:

It was early June and I was sitting by the pool in Providenciales, Turks and Caicos Islands, drinking a rum punch, when my cell phone rang. "Hi Matt, it's Greg." Morrisett, that is, at the time the CS department chair at Harvard. "Oh, hi Greg," I said, nonchalantly, as though I was used to getting phone calls from him while being thousands of miles away. "I have good news," he said, and told me that my tenure case had just been approved by the President. I believe my exact response was, "no shit!" (in the surprised and delighted sense, not the sarcastic sense). In that moment I felt that seven years of hard work had finally paid off.

Best album:

$O$ by Die Antwoord. Every now and then an album comes along that I get utterly addicted to, and listen on repeat for days on end until I'm sick of it... and then I listen some more. Die Antwoord's unbelievable mashup of white-boy rap, totally sappy techno, and over-the-top lyrics in English, Afrikaans, and Xhosa is one such album. This is not at all the kind of music I usually listen to, but something about the trashy hooks and ridiculous vocals is just too catchy. The best song is "Evil Boy," which has a brilliant video (warning: definitely NSFW). Also check out the faux documentary video "Zef Side." Runners up: Transference by Spoon; Root for Ruin by Les Savy Fav.

Best reason to memorize Goodnight Moon and "Elmo's Song:"

Being daddy to an eighteen-month-old. Fatherhood continues to wear well on me. As my little boy, Sidney, gets older, he only manages to be more amazing and more entertaining. These days he's running, talking, singing, parroting back pretty much anything he hears (gotta watch what I say around him), coloring with crayons, counting, naming everything in sight. It's also exhausting taking care of him at times, but totally worth it in every way.