mdwelsh

David Andersen at CMU teaches the undergraduate distributed systems course in Go: http://www.cs.cmu.edu/~dga/15-440/F12/

The problem is that no promotion = no job. So if you care about teaching, you need to get tenure.

People denied tenure in CS at Harvard have gotten senior (tenured) jobs elsewhere, but not in my opinion at places anywhere near as good.

You are right that being a mathematician at Harvard, it hardly matters if you get tenure or not. (In fact, for a long time you basically had to win the Fields Medal to get tenure in math at Harvard). Harvard is nowhere near as well known in Computer Science, and is more of a "top 20" rather than "top 5" school.

This isn't true in computer science at Harvard - I speak from experience, having gone through the tenure process there myself. Being denied tenure in CS at Harvard is about as bad as being denied tenure anywhere else; people don't usually end up in very good jobs afterwards. In my 8 years at Harvard, we awarded tenure to 5 junior faculty, and denied tenure to two.

The author of this article is a friend and former colleague (I had the office next door to hers at Harvard, when I was on the faculty there). Many of the reasons she cites for being "miserable" as a faculty member reflect why I left a tenured faculty job for industry. Nearly all junior faculty I know describe it as a survival process. Given this I fail to understand why being a professor remains such an attractive career path.

As a former professor at Harvard, this is a welcome move. However, I don't think it goes far enough, and it should have happened much sooner. One thing I will say: The fact that the administration felt the need to snoop on employee e-mail to "track down" a press leak underscores how backwards and insecure Harvard can feel at times. It's just shocking that anyone thought that this was a good idea, and that they continued to defend the practice once it came to light. Very sad.

The sensor networks research was work I did at Harvard prior to joining Google. I don't think Google is very interested in my deploying sensor networks on volcanoes, although (to be fair) I have not asked.

Thanks for the comments; I replied on the blog post itself. TL;DR: Even tenured profs care about helping their students get good jobs, which means publishing in top venues.

That's unfortunate. I'd be curious to know where you ended up taking a job. I have been surprised at how "academically inclined" Google is; however, I am sure there are groups here that have less interest in research-type endeavors than my group. Industry is by no means homogenous in this regard, which is why I decided to save that discussion for a later post.

I work for Google, and I think it's an awesome place to work, but I can see in my two years there how things have been changing in subtle ways. It's not a small company anymore, which hasn't changed how "cool" it is, but does mean that with so many other moving pieces that it's not as lean as a startup, where someone could - in principle - redo everything from scratch. The complaints I've heard from Xooglers tend to center around the technical aspect of working with a much larger codebase and increased ossification, rather than the company culture.

Still - Google has the spirit of a startup at its core. Engineers run the place, not execs. I like to say that there is very little "adult supervision" at Google; nearly all technical decisions are made bottom-up by engineers, and there is an active element at the center of the company culture to Do Things The Right Way.

If by "cool place to work" you mean, working with smart people, lots of perks (free food, massage, on-site doctor, all that), and a culture centered around doing amazing things, then yes, it's a cool place to work.

This is the best book on technical interviews for places like Google:

http://www.amazon.com/Cracking-Coding-Interview-Programming-...

Google is intentionally not blurring the faces on these images.

Here's Google's Seattle office, same deal - no faces blurred. http://goo.gl/maps/h5mYC

An Interplanetary Internet is not a joke: It's been a serious field of study for a while. There is a SIG on the topic, and lots of work has been done to think about how Internet protocols would work across interplanetary distances and frequent disconnections:

http://www.ipnsig.org/aboutstudy.htm

Pretty amazing memoir. Does a nice job of capturing the ups and downs of the grad student experience. Phil - consider distilling this down as a blog post or two - lots of good lessons here, but given the length they might be lost on most or your potential readers.

Thanks!

Also keep in mind it's using the Chrome networking stack, just not the rendering and JS engine.

Note that Chrome on iOS does use the Chrome networking stack, which has a lot of enhancements - including SPDY.

Mark - thanks for posting these. I was the recipient of my own batch of such rejection letters during my faculty search in 2002, so I know the feeling exactly. I ended up going to Harvard (not bad!) but the sting of rejection still hurts, no matter where it's from. These days I take it most universities do everything by email, but back in 2002 it was still almost exclusively done by paper mail. Somehow a paper rejection letter feels "nicer" than a rejection email.

This looks awesome. Does anyone know if SPDY support is in this release?

SPDY does not technically require TLS, but It's the Right Thing To Do [tm]. According to Mike Belshe, there are two reasons that SPDY was designed to use TLS. The first was pragmatic: Middleboxes on the Internet wouldn't be able to pass through non-HTTP traffic, so unless a different port was used, the only way to punch through the various proxy layers was to use end-to-end security. But the other reason is just as important: It's 2012, folks. It seems insane that most Web traffic goes in the clear. Browsers are fully capable of doing the SSL handshake without incurring a major performance cost - even on mobile devices. Finally, we may not get another chance to change the web protocol stack for another 15 years, so it's best to get it right now.

Sorry for not being clear. I completely agree that Opera's experience is relevant and useful. They have done some great work on optimizing mobile web performance and it would be fantastic to draw on that expertise to make open standards which everyone can benefit from. However, don't forget that SPDY and related technologies create a problem for Opera, which is based on a closed protocol and ecosystem. Personally, I believe in an open web based on open technologies which can be implemented by anyone. Without releasing code or a spec, it's easy to take a position that your approach is better - since nobody can scrutinize you to prove otherwise.

There's a big difference between having a closed, proprietary protocol and releasing something as open source with a public spec.

We wanted to use a real phone to accurately capture the performance of the phone hardware, browser (Chrome), and OS (Android). For example, JavaScript runs much more slowly on most mobile platforms than it does on desktop browsers, and we wanted to ensure our results were not skewed by that.

Hi Juho,

I'm the guy who did this study at Google. I agree with your criticisms that the measurement setup does not reflect real network conditions in all cases. However, we have done a tremendous amount of measurement on real mobile networks as well, and settled on this approach after a lot of iterating and tuning to come up with what (we believe to be) a fairly realistic setup that - most importantly - achieves repeatable results. This was a deliberate tradeoff.

We have measured mobile networks all over the world and observe that the network variation across space and time is incredibly high. It's pretty much meaningless to talk about "real mobile network conditions", since the conditions you measure in an office in Seattle are so vastly different than what you get on a train in Finland or a highrise in New York. The simple throttling we did does, in fact, accurately reflect HTTP and SPDY load times for those specific network conditions, which were meant to be representative of major carriers in the US.

You're right that we did not account for network latency to the origin server, but I would not expect that to skew the results in favor of either protocol, since the last mile is the slow link in this case.

The DNS overhead was an artifact of the test setup, but HTTP and SPDY should have the same number of required DNS lookups in both cases.

Feel free to drop me a line (my contact info is on the original article)!