Guest Post: Why I'm staying at Harvard (by Michael Mitzenmacher)

[Michael Mitzenmacher is a professor of Computer Science and the Area Dean for Computer Science at Harvard. He is a dear friend and colleague and has been one of the role models for my own career. Michael wanted to respond to my earlier blog post on leaving Harvard with his own reasons for staying; I am only too happy to oblige. (I swear I did not ghost write this.) You can read more of Michael's own blog here, though he's not posting much these days. --MDW]

To begin, I'd like to say how sorry we are at Harvard that Matt's not returning.  Matt's been a great colleague, continually pushing to make CS at Harvard better.  His enthusiasm and tenaciousness have made us tangibly better in numerous ways.  I, personally, will miss him a lot.  Matt pushes hard for what he believes in, but in my experience he's always done so with open ears and an open mind.  We're losing a leader, and Google is lucky to have him.  I have no doubt he'll do great things for the company, and maybe even earn them another billion or two.

While Matt's decision has been a blow to CS at Harvard, I'm optimistic that our plan for growth will, eventually, make up for that loss.  My job as Area Dean is to try to make that happen as soon as possible.  I don't want to suggest that replacing Matt will be easy, but rest assured we'll be on the case.

I'd also like to say that I think I understand Matt's reasons for leaving.  I'm glad to have him write "I love Harvard, and will miss it a lot."  And how could I disagree with statements like "The computer science faculty are absolutely top-notch, and the students are the best a professor could ever hope to work with. It is a fantastic environment, very supportive, and full of great people."  But I know from previous talks with him that he hasn't always loved being a professor.  And that's what I'll try to write about the rest of the post.

I think there's a sense in academia that people get PhD's so that they can become professors.  Most graduate students have that point of view going in -- their experience with research professionals at that point is essentially entirely with faculty.  And most professors encourage students to have that goal.  Some of that, I think, is that most professors like their job (unsurprisingly), and some may not have other experiences to suggest to their students.  And some of it may be more calculated.  One measure of a faculty member's success is how many faculty offspring they've produced.

But being a faculty member is not for everyone.  As Matt has described in this blog, and I in the past have described in my blog, being a professor is probably not exactly what most people expect.  Besides teaching and research, your time gets taken up with administration, managing (graduate) students, fundraising, and service to your scientific community.  It's perhaps absurd to expect that everyone who starts out in a PhD program be interested in all these various aspects of the job.  And, fortunately, in computer science, there are still many other compelling options available.

As Matt says, at Google, "I get to hack all day."  That's just not true as a faculty member -- time for actual hacking is usually pretty small, and more of your time is spend managing others to hack for you.  (This is a complaint I've heard from many faculty members.)  I can understand why Google would be a very appealing place for someone who wants to write code.  I'm sure Matt will come to miss some of the other aspects of being a professor at some point, and I'd imagine Google will to some extent let him entertain some of those aspects.

One of the comments suggested money must be a motivation.  For some people who have to make this choice, maybe it is.  (See Matt's comments on the post below for his take on that.)  So what?  Again, it's good that in our field there are good options that pay well.  That's a big plus for our field, especially if we accept the fact that not everyone can be or wants to be a professor.  But as Matt says, professors at Harvard (and top 20 institutions in general) are doing just fine, and money probably isn't the main issue for those who choose a different path.


I suppose the question that's left is why I'm staying at Harvard -- that is, why I still like being a professor.  (And thank you to those of you who think the obvious answer is, "Who else would hire you?")  I enjoy the freedom of working on whatever I find interesting; being unrestricted in who I choose to talk to about research problems and ideas; having the opportunity to work with a whole variety of interesting and smart people, from undergraduates to graduate students to CS colleagues all over the globe to math and biology professors a few buildings down; the ample opportunity to do consulting work that both pays well and challenges me in different ways; the schedule that lets me walk my kids to school most every day and be home for dinner most every night; and the security that, as long as I keep enjoying it, I can keep doing this job for the next 30+ years.

The job is never boring.  On any given day, I might be teaching, planning a class, working with students, thinking, writing a paper, writing some code, reading, listening to a talk, planning or giving a talk, organizing an event, consulting in some form, or any other manner of things. In the old days, I wrote a blog.  These days, I'm administrating, making sure our classes work smoothly, our faculty are satisfied and enabled to do the great things they do, and we're able to continue to expand and get even better.  Once I wrote a book, and someday I hope to do that again.  Perhaps the biggest possible complaint is that there's always something to do, so you have to learn to manage your time, say no, and make good decisions about what to do every day.  As someone who hates being bored, this is generally a good feature of the job for me.

And Harvard, I find, is an especially great place to work.  We attract some of the most amazing students.  Our still small-ish CS faculty really works together well; we all know who each other are, we keep aware of what we're all doing research-wise, we collaborate frequently, and we compromise and reach consensus on key issues.  Outside of the CS faculty, there's all sorts of interesting people and opportunities on campus and nearby.  Boston is a great city (albeit too cold and snowy in the winter).

Other profs have made similar comments in Matt's post -- there's a lot to like about the job, and at the same time, it's not the best choice for everyone.  Of course I don't like everything about the job.  Getting funding is a painful exercise, having papers rejected is frustrating and unpleasant, and not every student is a wondrous joy to work with.  I sometimes struggle to put work away and enjoy the rest of my life -- not because of external pressure (especially post-tenure), but because lots of my work is engaging and fun.  Of course that's the point -- there's good and bad in all of it, and people's preferences are, naturally, vastly different.  I don't think anyone should read too much into Matt's going to Google about the global state of Computer Science, or Professordom, or Harvard, or Google.  One guy found a job he likes better than the one he had.  It happens all the time, even in academia.  It's happened before and will happen again.

But I'm happy with my job right now.  In fact, I'm pretty sure my worst day on the job this year was the day Matt told me he wasn't coming back.  We'll miss you, Matt, and best of luck in all your endeavors.

Why I'm leaving Harvard

The word is out that I have decided to resign my tenured faculty job at Harvard to remain at Google. Obviously this will be a big change in my career, and one that I have spent a tremendous amount of time mulling over the last few months.

Rather than let rumors spread about the reasons for my move, I think I should be pretty direct in explaining my thinking here.

I should say first of all that I'm not leaving because of any problems with Harvard. On the contrary, I love Harvard, and will miss it a lot. The computer science faculty are absolutely top-notch, and the students are the best a professor could ever hope to work with. It is a fantastic environment, very supportive, and full of great people. They were crazy enough to give me tenure, and I feel no small pang of guilt for leaving now. I joined Harvard because it offered the opportunity to make a big impact on a great department at an important school, and I have no regrets about my decision to go there eight years ago. But my own priorities in life have changed, and I feel that it's time to move on.

There is one simple reason that I'm leaving academia: I simply love work I'm doing at Google. I get to hack all day, working on problems that are orders of magnitude larger and more interesting than I can work on at any university. That is really hard to beat, and is worth more to me than having "Prof." in front of my name, or a big office, or even permanent employment. In many ways, working at Google is realizing the dream I've had of building big systems my entire career.

As I've blogged about before, being a professor is not the job I thought it would be. There's a lot of overhead involved, and (at least for me) getting funding is a lot harder than it should be. Also, it's increasingly hard to do "big systems" work in an academic setting. Arguably the problems in industry are so much larger than what most academics can tackle. It would be nice if that would change, but you know the saying -- if you can't beat 'em, join 'em.

The cynical view is that as an academic systems researcher, the very best possible outcome for your research is that someone at Google or Microsoft or Facebook reads one of your papers, gets inspired by it, and implements something like it internally. Chances are they will have to change your idea drastically to get it to actually work, and you'll never hear about it. And of course the amount of overhead and red tape (grant proposals, teaching, committee work, etc.) you have to do apart from the interesting technical work severely limits your ability to actually get to that point. At Google, I have a much more direct route from idea to execution to impact. I can just sit down and write the code and deploy the system, on more machines than I will ever have access to at a university. I personally find this far more satisfying than the elaborate academic process.

Of course, academic research is incredibly important, and forms the basis for much of what happens in industry. The question for me is simply which side of the innovation pipeline I want to work on. Academics have a lot of freedom, but this comes at the cost of high overhead and a longer path from idea to application. I really admire the academics who have had major impact outside of the ivory tower, like David Patterson at Berkeley. I also admire the professors who flourish in an academic setting, writing books, giving talks, mentoring students, sitting on government advisory boards, all that. I never found most of those things very satisfying, and all of that extra work only takes away from time spent building systems, which is what I really want to be doing.

We'll be moving to Seattle in the spring, where Google has a sizable office. (Why Seattle and not California? Mainly my wife also has a great job lined up there, but Seattle's also a lot more affordable, and we can live in the city without a long commute to work.) I'm really excited about the move and the new opportunities. At the same time I'm sad about leaving my colleagues and family at Harvard. I owe them so much for their support and encouragement over the years. Hopefully they can understand my reasons for leaving and that this is the hardest thing I've ever had to do.

SenSys 2010 in Zurich

Photo from http://www.flickr.com/photos/aforero/542248140

I just got back from Zurich for SenSys 2010. I really enjoyed the conference this year and Jan Beutel did a fantastic job as general chair. The conference banquet was high up on the Uetliberg overlooking the city, and the conference site at ETH Zurich was fantastic. We also had record attendance -- in excess of 300 -- so all around it was a big success. I didn't make it to all of the talks but I'll briefly summarize some of my favorites here.

Sandy Pentland from the MIT Media Lab gave a great keynote on "Building a Nervous System for Humanity." He gave an overview of his work over the years using various sensors and signals to understand and predict people's behavior. For example, using various sensors in an automobile it is often possible to predict in advance whether someone is about to change lanes, based on subtle prepatory movements that they make while driving. His group has also used wearable sensors to gather data on conversational patterns and social interactivity within groups, and used this data to study practices that influence a business' productivity. This was an amazing keynote and probably the best we have ever had at SenSys -- very much in line with where a lot of work in the conference is headed.

The best paper award on Design and Evaluation of a Versatile and Efficient Receiver-Initiated Link Layer for Low-Power Wireless was presented by Prabal Dutta. This paper describes a new MAC layer based on receiver initiation of transmissions: receivers send probe signals that are used to trigger transmissions by sending nodes with pending packets. Their approach is based on a new mechanism called backcast in which senders respond to a receiver probe with an ACK which is designed to constrictively interfere with multiple ACKs being transmitted by other sending nodes. This allows the receiver probe mechanism to scale with node density. Because A-MAC does not rely on receivers performing idle listening, cross-channel interference (e.g., with 802.11) does not impact energy consumption nearly as much as LPL.

There were a bunch of talks this year on use of cell phones and other sensors for participatory sensing applications. One of my favorites was the paper on AutoWitness from Santosh Kumar's group at the University of Memphis. In this work, a small tag is embedded within a high-value item (like a TV set). If the item is taken from the home, accelerometer and gyro readings are used to determine its probable location. Using HMM-based map matching they showed that they can reconstruct the path taken by a burglar with fairly high accuracy.

Chenyang Lu from WUSTL presented a paper on Reliable Clinical Monitoring using Wireless Sensor Networks: Experience in a Step-down Hospital Unit. This paper presents one of the first studies to make use of low-power wireless sensors in a real hospital environment with real patients. My group spent about seven years working on this problem and we were often frustrated at our inability to get medical personnel to sign on for a full-scale study. Chenyang's group managed to monitor 46 patients in a hospital over 41 days (but only three patients at a time). Their paper showcases a lot of the challenges involved in medical monitoring using wireless sensors and is a must-read for anyone working in the area.

Finally, Steve Dawson-Haggerty from Berkeley presented his work on sMAP, a framework for tying together diverse sensor data for building monitoring. Steve's observation is that while different companies have worked on various protocols for standardizing building monitoring applications, most of these systems are highly proprietary, vertically-integrated nightmares of multiple entangled protocols. Steve took a "Web 2.0" approach to the problem and designed a simple REST-based API permitting a wide range of sensors to be queried through a Web interface. This is a really nice piece of work and demonstrates what is possible when a clean, open, human-centric design is preffered over a design-by-committee protocol spec with twenty companies involved.

Speaking of companies, one disappointing aspect of this years' conference is that there were very few industrial participants. None of the papers were from companies, and only a couple of the demos had any industrial affiliation. Part of the reason for this is that the conference organizers didn't approach many companies for support this year, since the budget was adequate to cover the meeting expenses, but this had the negative effect of there being essentially zero industrial presence. My guess is that the companies are going to the IEEE sensor nets conferences, but I am deeply concerned about what this means for the SenSys community. If companies aren't paying attention to this work, we run the risk of the wheels of innovation grinding to a halt.

There was one talk this year that was highly controversial -- Tian He's group from University of Minnesota presented a paper on an "energy distribution network" for sensor nets. The idea is to allow sensor nodes to push energy around, in this case, using wires connecting the nodes together. Unfortunately, the presenter did not justify this design choice at all and the only experiments involved very short (1 meter) cables between nodes. It seems to me that if you connect nodes together using wires, you can centralize the power supply and bypass the need for a low-power node design in the first place. The fact that the presenter didn't have any good arguments for this design suggests that the research group has not spent enough time talking to other people about their work, so they've built up a herd mentality that this actually makes sense. I don't think it does but would love to hear some good arguments to the contrary.

Apart from SenSys, I had the chance to (briefly) visit Timothy Roscoe at ETH Zurich as well as connect with some colleagues at the Google Zurich office. ETH Zurich is a very exciting place: lots happening, lots of faculty growth, tons of resources, good students and postdocs. I was very impressed. Even more impressive is Google's office in Zurich, which has the most over-the-top design of any of the Google offices I've visited so far (including Mountain View). The office is beautifully laid out and has a bunch of humorous design touches, including an indoor jungle and firepoles that connect the floors (with a helpful sign that reads, "don't carry your laptop while sliding down the pole.")

Conference talk pet peeves

I'm sitting here at SenSys 2010 in Zurich and listening to some pretty interesting -- and also some pretty dull -- talks on the latest research in sensor networks. Now seems like an appropriate time for a blog post I've been saving for a while -- some of the things that really annoy me when I'm listening to a talk. Of course, I'm sometimes guilty of these myself, and I'm not the best speaker either. But I guess I have license to gripe as a listener.

There are lots of tips on there on how to give a good talk. David Patterson's "How to give a bad talk" is a great summary of what NOT to do. Some of these things are fairly obvious, like not cramming too much text on one slide, but others I see happen again and again when I'm listening to talks at a conference.

The dreaded outline slide: Nearly every 25-minute talk in a systems conference has the same format. Why do speakers feel compelled to give the mandatory outline slide --

"First, I'll give the motivation and background for this work. Next, I'll describe the design of FooZappr, our syetem for efficient frobnotzing of asynchronous boondoggles. Next, I'll describe the implementation of FooZappr. Then, I will present evaluation, and finally, related work and conclusions..."

After having seen several hundred such talks I have this memorized by now, so I don't think it is a good use of time. An outline slide is sometimes a good idea for a longer talk, but it should have some content -- guideposts for the audience, or highlights of the major ideas. This is rarely needed for a short conference talk.

Reading the slides: The number one thing that drives me up the wall is when the speaker simply reads the text on the slide, or essentially says the same thing in slightly different words than what is printed on the bullets. This is lazy, and suggests that the talk hasn't been rehearsed at all. It's also the fastest way to bore the audience. Most members of the audience have two parallel reception channels: visual and auditory -- so I try to use both at once and provide (slightly) redundant information across the two channels in case of loss (e.g., tuning out the slide).

No sense of design: It can be physically painful to watch an entire talk crammed full of multiple fonts, clashing colors, inconsistent use of graphics, and that awful PowerPoint clip art (you know the ones: skinny stick figures scratching their heads). Modern presentation software, including PowerPoint, lets you design beautiful and visually compelling talks -- use it! If you insist on coming up with your own template, at least use the colors and fonts in a minimal and consistent way. I tend to use the Harvard crimson banners on my slides and the same color for highlight text. A grad student once complemented me on the beautiful font choice in my talk -- it was Helvetica. You shouldn't spend too much time on this, after all, if your slides look good but have terrible content, it's not worth it.

No sense of humor: I've lost count of how many conference talks I've heard that are nothing more than dry recitations of the technical content of the paper. No attempt is made at humor anywhere in the talk - not a joke to warm up the audience, or at least a visual joke somewhere in the slides to wake people up a bit. A conference talk is entertainment (albeit an obscure kind of entertainment for an incredibly dorky audience) -- the speaker should at least make some effort to make the talk interesting and delightful. Most conference attendees spent hundreds of dollars (thousands if you include travel) for the privilege of listening to your talk, so you owe it to them to deliver it well. This is not to say that you should overload the talk with jokes, but breaking up the presentation with a bit of levity never hurt anyone.

Keep in mind that a conference talk is meant to be an advertisement for your paper. You do not have to cram every technical detail in there. What will the audience remember about your talk? I'll never forget Neil Spring's talk on ScriptRoute where he used a bunch of ridiculous custom Flash animations.

Of course, the talk delivery matters tremendously. If you're one of those dull, monotonic speakers or have a thick accent, you are probably not going to get a reputation as a good speaker. If you sound totally bored by your talk, the audience will be too. Some grad students are surprised that this matters so much and think it shouldn't -- but if you're planning on pursuing an academic career, you have to give a LOT of talks. So you should get good at it.

"Let's take that offline." This is a frequent response to a question that the speaker doesn't want to answer. I've heard speakers jump immediately to this rather than make any attempt whatsoever of answering. This has become far too socially acceptable at conferences and I think questioners (and session chairs) should push back. It is occasionally OK to take a discussion offline if it is going to be a lengthy discussion or there's clearly no agreement between the speaker and questioner, but I think speakers should be expected to answer questions posed after the talk.

Finally, with digital cameras there's an increasing trend of audience members taking photos of every talk slide (sometimes for every talk). Here at SenSys there's someone who is taking a video of every talk on his cell phone. I find this fairly obnoxious, especially when the photographer insists on using a flash and leaving on the camera's shutter "beep". If you want my slides, just ask me and I'll send you the PPT. I also think it's rude to take a video of a talk without asking the speaker's permission.