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.