Saturday, January 22, 2011

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.

Thursday, January 13, 2011

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

Tuesday, January 4, 2011

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.

Startup Life: Three Months In

I've posted a story to Medium on what it's been like to work at a startup, after years at Google. Check it out here.