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.

Day in the Life of a Googler

I was thinking recently about how different my workdays are now that I'm at Google, compared to the faculty job at Harvard. The biggest difference is that I spent nearly 90% (or more) of my time writing code, compared to Harvard where I was lucky if I got half an hour a week to do any programming. I also spend a lot less time at Google procrastinating and reading a zillion stupid websites -- mostly because I'm enjoying the work a lot more.

Here's a short rundown of my typical day at Google:

6:30am - Wake up, get son up, shower, breakfast, take dog to the park.

8:30am - Leave for work (I take the subway most days).

9:00am - Arrive at work. Type passwords into half a dozen different windows to get my work environment back to a sane state. Check email. Check on status of my several jobs running in various datacenters. Page in work from day before.

9:30am-10:15am - Work on code to add requested feature to the system I'm working on. Debug it until it's working, write a unit test or two. Fire off code changelist for review. Grab third free Diet Coke of the day.

10:15-11:00 - Switch git branches to another project. Take a look at code review comments from a colleague. Go through the code and address the comments. Build new version, re-run tests, re-run lint on the code to make sure it's working and looks pretty. Submit revised changelist and responses to comments.

11:00-11:30 - Switch git branches again. Rebuild code to be safe, then fire off a three-hour MapReduce job to crunch log data to analyze network latencies.

11:30 - 12:00 - Quick videoconference meeting with team members in Mountain View.

12:00-12:35 - Lunch of free yummy food in cafeteria. Regale coworkers with stories of Apple IIgs hacking when I was in middle school.

12:35-2:00 - Back at desk. Check email. Check status of MapReduce job - about halfway done. Respond to last set of comments from code review done in the morning and submit the code. Merge and clean up the git branch. Take a look at task list to decide what to work on next.

2:00-3:00 - Project meeting with teams in Cambridge, Mountain View, and elsewhere by videoconference. This is my only hour-long meeting of the whole week. It is mildly amusing and I mostly spend the time doing some light hacking on my laptop and hitting reload on the MapReduce status page to see if it's done yet. Check Buzz and post a snarky comment or two.

3:00-4:00 - Red Bull infusion to keep energy going for the rest of the day.  MapReduce is finally done. Generate graphs of the resulting data and stare at them for a while. Think about why the results are different than expected and write next version of code to generate another set of statistics. Try to get the code to the point where I can fire off another MapReduce before leaving for the day.

4:00-5:00 - Whiskey Thursday! Round up a group of colleagues to drink scotch and play Guitar Hero. (I have a nice collection of scotch under my desk. Somehow I have been designated as the guardian of the alcohol supply, which suits me fine.)

5:00 - Pack up laptop and head home.

5:30-8:00 - Dinner and family time until son goes to bed.

8:00 until bedtime - More hacking, if there's stuff I want to get done tonight, or make a few nice cocktails if not.

Contrast this to my typical work day at Harvard:

 6:30am - Wake up, get son up, shower, breakfast, take dog to the park

8:30am - Leave for work (a 20-minute walk from home to the office, and I bring the dog with me).

9:00am - Arrive at office. Check email. Groan at the amount of work I have to do before the onslaught of meetings in the afternoon.

9:15am - Start working on outline for a grant proposal. About three minutes later, decide I don't know what I want to write about so spend next 45 minutes reading Engadget, Hacker News, and Facebook instead.

10:00am - Try to snap out of the Web-induced stupor and try to make headway on a pile of recommendation letters that I have to write. Fortunately these are easy and many of them are cut-and-paste jobs from other recommendation letters I have written for other people before.

11:00am - Check calendar, realize I have only an hour left to get any real work done. Respond to some emails that have been sitting in my inbox for weeks. Email my assistant to set up three more meetings for the following week.

11:30am - Try to make some token headway on the grant proposal by drafting up a budget and sending off the three emails to various support staff to get the paperwork going. Make up a title and a total budget for the proposal that sound reasonable. Still undecided on what the project should be about.

12:00pm - Take dog out for a 20-minute walk around campus. Sometimes spend longer if we run into other dogs to play with.

12:30pm - Run over to Law School cafeteria to grab overpriced and not-very-appetizing lunch, which I eat sullen and alone in my office, while reading Engadget and Hacker News.

1:00pm - First meeting of the day with random person visiting from a random company in Taiwan who will never give me any money but wants me to spend half an hour explaining my research projects to them in extraordinary detail.

1:30pm - Second meeting of the day with second-semester senior who has suddenly decided after four aimless years in college that he wants to do a PhD at Berkeley or MIT. Explain that this will not be possible given zero research track record, but somehow end up promising to write a recommendation letter anyway. Mentally note which other recommendation letters I will cut and paste from later.

2:00pm - Realize that I have to give lecture in half an hour. Pull up lecture notes from last year. Change "2009" to "2010" on the title slide. Skim over them and remember that this lecture was a total disaster but that I don't have time to fix it now. 

2:30pm - 4:00pm - Give lecture on cache algorithms to 70 or so somewhat perplexed and bored undergrads. Try to make the lecture more exciting using extensive PowerPoint animations and wild gesticulations with the laser pointer. Answer a bunch of questions that remind me why the lecture was a disaster last year and vow to fix it before delivering again next year.

4:00-4:10pm - Hide in office with door closed trying to calm down after adrenaline rush of lecturing. Gulp large amounts of Diet Coke to re-energize and re-hydrate.

4:10-4:20pm - Check email. Check Engadget. Check Facebook.

4:30-5:00pm - Last meeting of the day with two grad students working on a paper due in less than a week. They have no outline and no results yet but are very optimistic that they will make it in time. Spend half an hour sketching ideas and possible graphs on the whiteboard while they scribble furiously in their notebooks. Make vague promises about reviewing a draft if I see one later in the week.

5:00pm - Walk home with my dog. This is the best part of my day.

5:30pm - Get home, immediately sit down to check enormous pile of email that accumulated while I was in lecture and meetings. Forward five new meeting requests to my assistant for scheduling next week.

5:45pm - 8:00pm - Family time, dinner.

8:00pm - Pretend to "work" by reading email and tinkering with PowerPoint slides for a talk I have to give the next week. Too exhausted to do anything useful, make a drink and read Engadget again. 

 

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.")