Programming != Computer Science

I recently read this very interesting article on ways to "level up" as a software developer. Reading this article brought home something that has been nagging me for a while since joining Google: that there is a huge skill and cultural gap between "developers" and "Computer Scientists." Jason's advice to leveling-up in the aforementioned article is very practical: write code in assembly, write a mobile app, complete the exercises in SICP, that sort of thing. This is good advice, but certainly not all that I would want people on my team spending their time doing in order to be true technical leaders. Whether you can sling JavaScript all day or know the ins and outs of C++ templates often has little bearing on whether you're able to grasp the bigger, more abstract, less well-defined problems and be able to make headway on them.

For that you need a very different set of skills, which is where I start to draw the line between a Computer Scientist and a developer. Personally, I consider myself a Computer Scientist first and a software engineer second. I am probably not the right guy to crank out thousands of lines of Java on a tight deadline, and I'll be damned if I fully grok C++'s inheritance rules. But this isn't what Google hired me to do (I hope!) and I lean heavily on some amazing programmers who do understand these things better than I do.

Note that I am not defining a Computer Scientist as someone with a PhD -- although it helps. Doing a PhD trains you to think critically, to study the literature, make effective use of experimental design, and to identify unsolved problems. By no means do you need a PhD to do these things (and not everyone with a PhD can do them, either).

A few observations on the difference between Computer Scientists and Programmers...

Think Big vs. Get 'er Done 

One thing that drove me a little nuts when I first started at Google was how quickly things move, and how often solutions are put into place that are necessary to move ahead, even if they aren't fully general or completely thought through. Coming from an academic background I am used to spending years pounding away at a single problem until you have a single, beautiful, general solution that can stand up to a tremendous amount of scrutiny (mostly in the peer review process). Not so in industry -- we gotta move fast, so often it's necessary to solve a problem well enough to get onto the next thing. Some of my colleagues at Google have no doubt been driven batty by my insistence on getting something "right" when they would rather just (and in fact need to) plow ahead.

Another aspect of this is that programmers are often satisfied with something that solves a concrete, well-defined problem and passes the unit tests. What they sometimes don't ask is "what can my approach not do?" They don't always do a thorough job at measurement and analysis: they test something, it seems to work on a few cases, they're terribly busy, so they go ahead and check it in and get onto the next thing. In academia we can spend months doing performance evaluation just to get some pretty graphs that show that a given technical approach works well in a broad range of cases.

Throwaway prototype vs. robust solution

On the other hand, one thing that Computer Scientists are not often good at is developing production-quality code. I know I am still working at it. The joke is that most academics write code so flimsy that it collapses into a pile of bits as soon as the paper deadline passes. Developing code that is truly robust, scales well, is easy to maintain, well-documented, well-tested, and uses all of the accepted best practices is not something academics are trained to do. I enjoy working with hardcore software engineers at Google who have no problem pointing out the totally obvious mistakes in my own code, or suggesting a cleaner, more elegant approach to some ass-backwards page of code I submitted for review. So there is a lot that Computer Scientists can learn about writing "real" software rather than prototypes.

My team at Google has a good mix of folks from both development and research backgrounds, and I think that's essential to striking the right balance between rapid, efficient software development and pushing the envelope of what is possible.

Measuring the mobile web is hard

I believe strongly that you can't solve a problem until you can measure it. At Google, I've been charged with making the mobile web fast, so naturally, the first step is measuring mobile web performance across a wide range of devices, browsers, networks, and sites. As it turns out, the state of the art in mobile measurement is a complete mess. Different browsers report completely different timings for the same events. There is very little agreement on what metrics we should be optimizing for. Getting good timing out of a mobile device is harder than it should be, and there are many broken tools out there that report incorrect or even imaginary timings.

The desktop web optimization space is pretty complicated, of course, although there's a lot more experience in desktop than in mobile. It's also a lot easier to instrument a desktop web browser than a mobile phone running on a 3G network. Most mobile platforms are fairly closed and fail to expose basic performance metrics in a way that makes it easy for web developers to get at them. We currently resort to jailbreaking phones and running tcpdump and other debugging tools to uncover what is going on at the network and browser level. Clearly it would be better for everyone if this process were simpler.

When we talk about making the mobile web fast, what we are really trying to optimize for is some fuzzy notion of "information latency" from the device to the user. The concept of information latency will vary tremendously from site to site, and depend on what the user is trying to do. Someone trying to check a sports score or weather report only needs limited information from the page they are trying to visit. Someone making a restaurant reservation or buying an airline ticket will require a confirmation that the action was complete before they are satisfied. In most cases, users are going to care most about the "main content" of a page and not things like ads and auxiliary material.

If I were a UX person, I'd say we run a big user study and measure what human beings do while interacting with mobile web sites, using eye trackers, video recordings, instrumented phones -- the works. Unfortunately those techniques don't scale very well and we need something that can be automated.

It also doesn't help that there are (in my opinion) too many metrics out there, many of which have little to do with what matters to the user.

The HTTP Archive (HAR) format is used by a lot of (mostly desktop) measurement tools and is a fairly common interchange format. Steve Souders' httparchive.org site collects HAR files and has some nice tools for visualizing and aggregating them. The HAR spec defines two timing fields for a web page load: onLoad and onContentLoad. onLoad means the time when the "page is loaded (onLoad event fired)", but this has dubious value for capturing user-perceived latency. If you start digging around and trying to find out exactly what the JavaScript onLoad event actually means, you will be hard-pressed to find a definitive answer. The folklore is that onLoad is fired after all of the resources for a given page have been loaded, except that different browsers report this event at different times during the load and render cycle, and JavaScript and Flash can load additional resources after the onLoad event fires. So it's essentially an arbitrary, browser-specific measure of some point during the web page load cycle.

onContentLoad is defined in the HAR Spec as the time when the "Content of the page loaded ... Depeding [sic] on the browser, onContentLoad property represents DOMContentLoad [sic -- should be DOMContentLoaded] event or document.readyState == interactive." Roughly, this seems to correspond to the time when "just" the DOM for the page has been loaded. Normally you would expect this to happen before onLoad, but apparently in some sites and browsers it can happen after onLoad. So, it's hard to interpret what these two numbers actually mean.

The W3C Navigation Timing API goes a long way towards cleaning up this mess by exposing a bunch of events to JavaScript including redirects, DNS lookups, load times, etc. and these times are fairly well-defined. While this API is supported by WebKit, many mobile browsers platforms do not have it enabled; notably iOS (I hope this will be fixed in in iOS5, we will see). The HAR spec will need to be updated with these timings, and someone should carefully document how effectively different browser platforms implement this API in order for it to be really useful.

The W3C Resource Timing API provides an expanded set of events for capturing individual resource timings on a page, which is essential for deep analysis. However, this API is still in the early design stages and there seems to be a lot of ongoing debate about how much information can and should be exposed through JavaScript, e.g., for privacy reasons.

A couple of other metrics depend less on the browser and more on empirical measures, which I tend to prefer.

Time to first byte generally means time to the first byte of the HTTP payload reception on the browser. For WebPageTest, this includes redirects (so redirects are factored into time to first byte). Probably not that useful by itself, but perhaps in conjunction with other metrics. (And God bless Pat Meenan for carefully documenting the measures that WebPageTest reports -- you'd be surprised how often these things are hard to track down.)

WebPageTest also reports time to first paint, which is the first time anything non-white appears in the browser window. This could be as little as a single pixel or a background image, so it's probably not that useful as a metric.

My current favorite metric is the above-the-fold render time, which reports the time for the first screen ("above the fold") of a website to finish rendering. This requires screenshots and image analysis to measure, but it's browser-independent and user-centric, so I like it. It's harder to measure than you would think, because of animations, reflow events, and so forth; see this nice technical presentation for how it's done. Video capture from mobile devices is pretty hard. Solutions like DeviceAnywhere involve hacking into the phone hardware to bring out the video signal, though my preference is for a high-frame-rate video camera in a calibrated environment (which happens to scale well across multiple devices).

One of my team's goals is to provide a robust set of tools and best practices for measuring mobile websites that we can all agree on. In a future post I'll talk some more about the measurements we are taking at Google and some of the tools we are developing.

Making Seattle my home

I moved to Seattle about 4 months ago, after having lived in Boston for a little more than seven years. Now that I've settled in a bit I thought now would be a good time to write up some of my thoughts on the city and lifestyle here.

The view from Kerry Park in Queen Anne, which was about a 10-minute walk from my house in Queen Anne - before I moved to Wallingford recently.

Upon leaving Boston, I could have moved pretty much anywhere. Most of the cities with a strong tech industry had good job opportunities for my wife, as well, and of course Google has offices in most major cities in the US. So we had plenty of options. We both went to Berkeley for grad school and absolutely love the Bay Area, but we decided not to move back there for a bunch of reasons. The main one being that I would have been working in Mountain View and my wife would have been in SF, and that would have meant a hell of a commute for either of us. It was also not clear that we would have been able to afford a decent house in the Bay Area in any neighborhoods that we would want to live. Our preference would have been to live in the East Bay, bit that would have made the commute problem even worse. With a two-year old son, I'm not willing to go through  an hour commute twice a day -- it's simply not worth it to me.

Seattle has a lot of what we were looking for. We live right in the middle of the city (in Wallingford) and for me it's a 10-minute bike commute (to the Google office in Fremont) along the shore of Lake Union, with views of downtown, the Space Needle, and Mount Rainier. It is a fantastic neighborhood with shops, bars, restaurants, playgrounds, and one of the best elementary schools in Seattle (John Stanford) just a few blocks away.

I realized at one point that I probably know more people in Seattle than any other city -- including Boston -- with the University of Washington, Microsoft, Amazon, and Google all here I had this large pre-fab social network already in place. The tech industry is huge here and there seems to be a very active startup community.

The geography here is absolutely stunning. Anywhere you go in Seattle you are surrounded by water, trees, snow-capped mountains. From our house we have a beautiful view to downtown Seattle and Lake Union, with seaplanes taking off and landing overhead. It is also a dense enough city that we can walk or bike to pretty much everything we would need; of course, a big part of this is because we live in Seattle proper, rather than the Eastlake communities of Kirkland, Bellevue, or Redmond, which tend to be more spread out.

This is totally the view from my house in Wallingford. Yes, I would like for that damn tree to not be in the way, but what can you do?

It is no surprise that Seattle is a far more relaxed and progressive place than Boston. A lot of this is, of course, the West Coast vs. East Coast distinction, and in a lot of ways Seattle exemplifies the West Coast aesthetic, much as Boston does the East. Way way more fixie bikes, tattoos, farmers markets, lesbians, hippies, and hippie lesbians with tattoos riding fixie bikes through farmers markets here in Seattle than anywhere in New England. In a lot of ways it's like San Francisco Lite -- a bit less edgy, more approachable, more gentrified, but still very forward-thinking. I feel very much like I belong here, whereas in Boston I always felt like a bit of an outsider.

So far I'm digging the restaurant and cocktail scene in Seattle, which is more adventurous and less stuffy than what you find in Boston (although Boston has some damn good food). I miss really good Chinese food (which is harder to find than you would expect), and surprisingly Seattle doesn't have a ton of great Mexican food options, although I happen to live about a block from the best taco truck in town. Thai and sushi are excellent here, and there seems to be a lot more casual, foodie-type places all over town which do crazy shit like Korean comfort food and ice cream sandwiches. 

What am I not so crazy about? Well, I'm on the fence about the weather. The summer has (mostly) been beautiful - 75 degrees, sunny, no humidity at all. Mixed in have been some cooler rainy days that feel out of place for the season. The first couple of months we were here, in April and May, it was rainy and overcast pretty much every day. I take it this is typical for Seattle. The long term question is whether I will be more or less content with this pattern than Boston, which has a much wider temperature range, a couple of months of unbearably cold and snowy weather each year, and sweltering humid summers. It remains to be seen.

Second, everyone in Seattle appears to be white. This is not true of course, but at least in the neighborhoods where I spend most of my time, there is a lot less racial and cultural diversity than Boston. My understanding is that this is due to largely historical reasons where minorities were shut out of many neighborhoods, but the effects persist today. I will ponder this more deeply the next time I'm sitting at a sidewalk café with my dog while sipping an organic soy latte and checking Google+ on my MacBook Pro. It's the thing to do here, you know.

How do you evaluate your grad students?

One of the issues that I always struggled with as an academic -- and I know many other faculty struggle with -- is keeping grad students on track and giving them useful feedback to help them along in their careers. PhD students often get lost in the weeds at some point (or many points!) during grad school. Of course, part of doing a PhD is figuring out what you want to work on and doing things that might seem to be "unproductive" to the untrained eye. On the other hand, many PhD students grind to a halt, spending months or even years on side projects or simply doing nothing at all. One problem my own students often had was working super hard to submit a paper and then doing almost no new work for 2-3 months while waiting to get the reviews back.

When a student gets stuck in a rut, how do you help them out of it? How do you help students clear a path to productivity?

One thing that many PhD programs lack is any regular and formal evaluation of a student's progress. Harvard never did anything formal, although I tried to get something going it did not last beyond one year -- not enough faculty cared to participate, and we couldn't agree on the process or desired outcomes. At Berkeley, every PhD student got a formal letter every year with a "letter grade" indicating how well you were doing and with some optional comments from your advisor on your overall progress. Although that feedback could have been delivered informally, there was a psychological impact to the formal letter and the idea that all of the professors were meeting in a smoky room to talk about your standing. CMU has its infamous  "Black Friday" where all the profs literally do get together to score the grad students. Not having been to CMU, I wonder how this was viewed by the students -- did they find this feedback valuable, stressful, or just plain annoying?

Although this kind of feedback can be useful, for many students it goes in one ear and out the other. I think that part of the reason is that there is often no penalty for doing poorly on a review -- about the only thing a PhD program can threaten you with is kicking you out, and most programs that I know of avoid that unless there's a case where a student has been totally unproductive for a period of several years. It's hard to get kicked out of grad school. By the same token there's little incentive to do well on a review: you're not going to graduate any sooner or get paid more. (Sidebar - should PhD programs pay high-performing grad students bonuses?)

The other issue is that these mechanisms are somewhat open loop in the sense that the student is not expected to lay out a plan and stick to it. Most PhD programs expect students to file some kind of formal plan of study or research leading towards their degree, but it is usually a matter of paperwork and is done just once, or maybe twice, during the course of the program. This has almost no value to the student and is just a matter of paperwork. My feeling is that students would benefit tremendously from a more frequent and formal planning process.

At Google, the approach we use for planning is based on OKRs, or "objectives and key results." Every employee and team is expected to come up with their OKRs for the coming quarter, and score the OKRs from the previous quarter in terms of how much progress was made towards each goal. This is extremely useful process since it gets you thinking about what you need to do over the next 3 months (which seems to be about the right planning horizon for most activities) and you have the chance to reflect on your successes and failures of the previous quarter. It's not expected that you achieve 100% of your goals -- if you are doing so, then your OKRs were not ambitious enough -- you should be shooting for a grade of 70-80%.

I wonder if grad students wouldn't benefit from using something like OKRs for planning their research. A student should be able to say what they are doing over the next 3 months. Looking back on the previous 3 months and grading your progress tells you whether you are generally on track. Having quarterly OKR scores can also help advisors point out where the student needs to improve and documents clear-cut cases where a student has been unproductive (something that both students and advisors are often in denial about). Thoughts?

My experience with Amazon Cloud Player

As I've posted here before, I'm an avid music fan and collector. A few years ago I decided to go all-digital with my music collection, and since then have mostly refused to buy CDs in favor of digital music online -- mostly from Amazon's (excellent) MP3 store, as well as iTunes. However, this created a new problem: where to keep the music, and how to keep it synced between my various devices -- home laptop, work laptop, work desktop, home desktop, phone, iPad. Lots of people have this problem. My music collection is now more than 50 GB and it's no small feat to keep it synchronized between devices.

For a while I had this crazy scheme where I would only buy new music on my home laptop (the "master" library) which I could sync directly to my phone. From the home laptop I would push new music (using rsync) to my home desktop, which would allow me to listen to it on the stereo at home (via a first-generation Squeezebox player). I would also push it to my desktop at Harvard, so I could listen at work. Once I moved to Google, syncing from home to work became more difficult, although not impossible -- but I could only do so when on the Google VPN, which I can only access on my work laptop. So I modified the aforementioned crazy scheme by syncing from the home laptop to my old desktop machine at Harvard, from which I would pull down new music to my work desktop and laptop. In this way, at least I always knew where the master copy was, and the flow of new data along any edge was always unidirectional, thereby avoiding sync conflicts.

Over time the complexity of this scheme became a real annoyance, especially since I could only buy new music when I was using my home laptop, and syncing to my iPhone and iPad required manually plugging them into that same machine.

So, about a month ago I switched over to using Amazon Cloud Drive, in the hopes that it would fix this problem once and for all. In terms of solving the sync problem, it has been a great success: all of my music now simply lives on Amazon’s servers, and (except for my phone) I don’t need to worry about syncing it to any other devices. For that, Amazon has a Cloud Player app for Android which can pull the music down to my phone directly, without having to stage it on any of my other machines. So I can buy music on the phone, which is immediately available in my Cloud Drive, and I can pull it down to the phone if I want to. (I even bought and downloaded an album to my phone while on an Alaskan Airlines flight, using the in-flight WiFi.) There is an amazing instant-gratification factor here: read about an album on Pitchfork, it’s in your library and on all of your devices in under a minute.

Now, I mostly listen to music at work using the Amazon Cloud Player in my web browser. I don’t even bother syncing a copy to my various machines, though from time to time I do download new music to my home laptop just to have a local backup (in case Amazon goes out of business or something).

Unfortunately, as a user experience goes, I think the web-based Cloud Player has a long way to go:

• The web interface is terribly slow, especially with a large music collection such as my own. I have more than 12,000 songs and 1,000 albums in the collection, and opening up the Web-based Cloud Player takes a good 20 seconds. The worst part is scrolling through the music’s “album” view: for some damn reason I always get a yellow spinner when paging through the set of albums, and it can take 20-30 seconds to load the album art for each page so I can see what I want to listen to. Plenty of other websites have solved the problem of previewing large numbers of images, so I can’t understand why Amazon’s site is so slow.
  
• I rarely have problems with the music playback, though keep in mind I am usually listening from Google’s very well provisioned network. (I also happen to live in Seattle, spitting distance from Amazon HQ, though I’m not sure how much that helps.) However, given that I generally have a few dozen other tabs open on my browser in several windows, I have noticed that the Cloud Player running in the background was inducing additional lag. Now, I only run Cloud Player from a different browser (Safari) dedicated to that purpose.
  
• Every 24 hours, the login credentials on the Cloud Player time out and it will stop playback immediately and force me to log in again. This is highly annoying, especially when I’m in the middle of rocking out to Gang Gang Dance. And of course, when I login again, the Cloud Player has forgotten its state so I have to wait 30 seconds to reload my music library and figue out which song I was listening to and fire it up again -- a good minute of rocking-out time lost. I can use Google docs, Gmail, and a bunch of other online services without having to enter my login credentials every day; why can’t Amazon solve this problem? Maybe it’s a licensing issue, but it makes for a painful user experience.
  
• When I first signed up, I had to run Amazon’s MP3 uploader to load my music library into their servers. Given that 99% of the music is available on Amazon’s own MP3 store -- and I suspect a good 15% of my library was originally purchased from same said store -- I was surprised that I had to go through this painful step. To add insult to injury, the uploader for some reason capped bandwidth at 500 Kbps or so, meaning it took nearly a week and a half to upload all my music. (Made even worse because the login credentials would time out every day and would not resume uploading until I logged in again.) I should have been able to upload my entire music library to Amazon in less than 20 hours on my 5 Mbps connection from home, so the artificial cap seems ridiculous.
  
• Somewhat humorously, when I buy new music from Amazon’s MP3 store, there is a delay before it shows up in my library. I can hit reload and watch each song being loaded into the library, and it seems to take a few seconds for each one to appear. I assumed that adding music from Amazon’s MP3 store to my Cloud Drive would be a matter of creating the S3 equivalent of a symlink, so what the hell is going on here?

Just for the record I have not yet tried Google Music, which is in beta, since I am too lazy to move my music collection over yet again. From what I have seen, the web interface is pretty similar so there's not a good enough reason -- yet -- to switch. I'm curious to see what Apple's iCloud is like, but I really like having my music collection liberated from Apple's DRM.

So, I am somewhat surprised at how bare-bones the Amazon Cloud Player is. Given that this is a web app, you would think there would be all kinds of great features that go beyond what you can do inside of a “closed” app like iTunes. For example, there’s no way to share a link to a song or album in Amazon’s MP3 store with Facebook or Twitter -- I have to go search for the listing on Amazon’s MP3 store by hand, and post that manually. This seems like a lost revenue opportunity for Amazon, since it’s hard to share with my friends online that I’m loving the new Bon Iver album and give them a link to buy it (hey, maybe with a referral discount).

Overall it's awesome to use this service and I love having my music everywhere all at once, and not having to manually maintain a library. If the web player were more sophisticated and responsive it would be a slam dunk.

Being Googley

I've been at Google for almost a year now and have been thinking back on what my expectations of the job would be like compared to what it has turned out to be. This got me thinking about corporate culture in general and how important it is for fostering innovation and being successful.

Google is well known for having a creative work environment with tons of perks -- free food, yoga classes, massage, on-site doctor. Here in Seattle, we can borrow kayaks to take out onto the shipping canal next to the building. (I am fond of telling people this but know full well that I am unlikely to ever take advantage of it.) On the surface these things might seem frivolous, but I think they go a long way towards creating an environment where people are passionate about what they do. The term we use is "being Googley," meaning, doing whatever it is that Google people do: thinking big, focusing on the user, not being evil, etc. On a more day-to-day basis, being Googley means turning out the lights when you leave a conference room, being friendly and helpful to new engineers, being a good citizen.

Google is by no means the only company like this: Yahoo, Facebook, and Amazon are great examples, and many other Internet-era startups follow a similar model. But this is miles away from what I thought corporate life would be like before I joined Google. To be sure, most of my prior exposure to corporate life (that is, before doing my PhD and becoming a professor) was through internships I did at a couple of older technology companies. I spent time writing code at a company that built semiconductor testers, as well as a large electronics company in Japan. I had also visited several large industrial research labs in the US, places that in some cases have been around for more than 50 years. I had a very hard time imagining myself taking a job at any of these companies: the sea of cubicles, drab beige walls, terrible cafeteria food, very few people under 40. Like Dilbert in real life. I wonder how those companies continue to attract top talent when there are places that are so much more appealing to work.

The Google culture is not just about lava lamps in the conference rooms though. The thing that surprised me the most is that there is very little hierarchy in the company: every engineer has the opportunity to create and lead new projects. It's not uncommon for something cool to start up with a few engineers working in their "20% time" -- GMail being one famous example. It is rare for a technical edict to be handed down from on high: projects are usually bottom up and are driven by what the engineers want to accomplish. To be sure, there are projects that could benefit from more adult supervision: things can go off the rails when you don't have enough management. But it's amazing what a merry band of hackers can put together without a lot of imposed structure or artificial constraints from the Pointy Haired Boss. I think the result is that engineers feel a lot of ownership for what they create, rather than feeling like they are just building something to make management happy.

When I was in the Google office in Cambridge, I worked on the team that builds Google's content delivery network -- a huge system that carries a significant chunk of the Internet's traffic (mostly YouTube). Almost everyone on the team was a good 10 years younger than I am (and way smarter, too). There was very little oversight and everyone kind of pitched in to keep the thing running, without anyone having to be told explicitly what to do. I was amazed that you could run such a large, complex project like this, but it seems to work. It's a hacker culture at a large scale. Companies like Facebook and Amazon are run pretty much the same way. All of this seems to turn the conventional wisdom about what it takes to run a successful company upside down. This won't be a surprise to anyone who spent time at startups in the last 10 years, but I'm new to this stuff and surprised that it even works.

The changing face of Computer Science education

The New York Times has a great article today on changing attitudes towards CS, driven in part by movies like "The Social Network." Apart from the movie's (glossy and inaccurate) depiction of what it's like to be a hacker, there's something else going on here: the fact that CS students can jump in and apply their knowledge to build great things. At Harvard, countless undergrads taking the introductory CS50 class are producing games, websites, and iPhone apps -- some of which are good enough to turn into commercial products. I don't know of any other field where this is possible after taking just a single semester's worth of courses.

Of course, it wasn't always this way. For a very long time, Computer Science education at most Universities was grounded in the abstract and theoretical. Undergraduates rarely got the opportunity to build "real" applications or products. After all, before the advent of cheap, powerful PCs, a department might have one computer for the entire class, and its main purpose was to sit in a walled-off machine room and spit out numbers on a printout -- hardly inspiring. I did my undergrad degree at Cornell, and the first class I took was taught in Scheme -- a language I have never used since -- although the projects were fun for someone like me (implementing a public key cryptosystem, and doing some neat machine vision algorithms). Of course, this was before the Web, iPhones, and Facebook, so CS class "projects" tended to be somewhat dry back then.

Unfortunately, there are still too many vestiges of this old fashioned approach to Computer Science evident in the curriculum. It is largely a generational thing. At Harvard, I had a hell of a time convincing some of the senior faculty that we should be teaching all CS students the fundamentals of computer systems, like how a process works, what a cache is, how to program using threads. (Of course, like most CS degree programs, Harvard still requires all students to learn the finer points of nondeterministic finite state automata and arcane discrete mathematics. Harry Lewis, who teaches this class, once described this to me as "eating your vegetables.")

A few years ago, I was asked to take over teaching CS50, Harvard's introductory CS course. Since the semester was right around the corner, I didn't have time to revamp the course, and agreed to do it only if I could teach the original course material with few changes. I took a look at the existing syllabus. The first lecture was about the "history of computing" and was full of black and white pictures of Babbage and ENIACS and men in horn-rimmed glasses looking over printouts in a terminal room somewhere. This was not a promising start. The next six lectures explained in painful detail -- down to machine instructions and the bit representation of integers -- how to write a single program: How to convert Fahrenheit to Celsius. This being the only program that students saw for the first month or so of the course, it's no wonder that the course did not have broad appeal. This kind of material probably worked very well in the early 1990's, but not so today -- the field has changed, and what students are looking for has changed too.

I passed on teaching CS50, and it's a good thing I did -- Harvard hired David Malan, who is infinitely more energetic and likable than I am, to teach it instead. David completely reworked the course from the perspective of someone who learned CS in the PC and Internet era. He had students hacking iPhone apps, writing PHP and JavaScript, building websites. Over the next few years, enrollment in the course has nearly quadrupled -- it's become one of the "must take" courses at Harvard. He has done an amazing job.

Of course, there is a risk in going too far down this fun, project-oriented route. Computer Science is not a vocational program, and it's important for students to graduate with a deep understanding of the field. It's true that you can do amazing things with existing languages and tools without learning much about the deeper theory and foundations. Still, I think it's great to attract students with a fun, application-oriented course that gets them excited about the field, and hit them later with the more abstract ideas that might seem less relevant at the outset.

One problem is that the classes that follow CS50 are nowhere near as exciting -- they don't have monthly pizza parties and free Facebook schwag at the end of the semester -- so keeping students in the program beyond the intro course can be a challenge. But I think it's important for universities to consider where CS undergrads are coming from and try to meet them there, rather than to teach the way it was done 30 years ago, on a PDP-11 running LISP.