Skip to main content

Visit to Utah

I had a great visit to the University of Utah this week, and gave a distinguished lecture on "A New Era of Resource Responsibility for Sensor Networks." I had never visited Utah before, and am pretty impressed with their CS department overall. The folks there seem to get along very well and have considerable strength in graphics, languages, and embedded systems in particular. Their Scientific Computing Institute could be a model for what we've been doing at Harvard with the Initiative in Innovative Computing.

Of course, Utah is famous for the Flux research group, led by the late and great Jay Lepreau. Jay was one of my role models and I admired his approach to building real systems and getting others to use them (our MoteLab testbed was heavily inspired by Emulab.) I'm sorry that I never got a chance to visit Utah while Jay was still with us.

One thing that struck me was that the group is built around full-time research staff, which has enabled them to build substantial research infrastructure (such as Emulab) and continue to expand and maintain it beyond the typical timeframe of a graduate student. (It's also true that research staff tend to think less in terms of papers+thesis and more in terms of writing useful code. It's sad that these things are not always compatible in the course of academic research.) It's not a model I've seen used much in other systems groups -- likely because it requires a lot of funding to make it sustainable. Then again, Jay was a powerhouse when it came to bringing in research funds.

It's great to see that the Flux group is still going strong. I'm sure Jay would be really glad to see it.

(By the way, HotOS just won't feel the same without Jay there. We need to appoint an honorary Lepreau Proxy. Any volunteers to ask snarky, meandering questions after each talk?)

Comments

  1. Why couldn't other departments have a higher staff/postdoc : grad student ratio? When you write an NSF/DARPA/whatever grant, do they really care if your staff budget is going to grad students rather than staff and postdocs? Or is it that grad students cost less per person than staff/postdocs?

    ReplyDelete
  2. In general:

    a) grad students are cheaper than staff (sometimes 0.5x)
    b) NSF prefers to fund grad students
    c) Staff always need 12mo support, grad students frequently go on internships, get fellowships, and, if somehow funding suddenly drys up can usually TA (plus time to Ph.D. is ~5-6 years while staff can stay for a decade or more)
    d) Consequently, many people only want to hire staff when they feel confident about being able to provide significant job security... a-c mean that you need to feel flush to do this.

    All that said, I think people are probably overly conservative here since my experience is that good experienced staff are worth their weight in gold.

    ReplyDelete

Post a Comment

Popular posts from this blog

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 m…

Rewriting a large production system in Go

My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go. I say "almost" because one component of the system -- a library for transcoding between image formats -- works perfectly well in C++, so we decided to leave it as-is. But the rest of the system is 100% Go, not just wrappers to existing modules in C++ or another language. It's been a fun experience and I thought I'd share some lessons learned.

Why rewrite?

The first question we must answer is why we considered a rewrite in the first place. When we started this project, we adopted an existing C++ based system, which had been developed over the course of a couple of years by two of our sister teams at Google. It's a good system and does its job remarkably well. However, it has been used in several different projects with vastly different goals, leading to a nontrivial accretion of cruft. Over time, it became apparent that for us to continue to innovate rapidly wo…

Running a software team at Google

I'm often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds like a big step down. Job titles aside, I'm much happier and more productive in my new role than I was in the 8 years at Harvard, though there are actually a lot of similarities between being a professor and running a software team.

I lead a team at Google's Seattle office which is responsible for a range of projects in the mobile web performance area (for more background on my team's work see my earlier blog post on the topic). One of our projects is the recently-announced data compression proxy support in Chrome Mobile. We also work on the PageSpeed suite of technologies, specifically focusing on mobile web optimization, as well as a bunch of other cool stuff that I can't talk about just yet.

My official job title is just "software engineer," which is the most common (and coveted) role at Google. (I say "coveted&quo…