The NCSSM 2014 commencement address

This morning I had the distinct pleasure of delivering the commencement address at the North Carolina School of Science and Math, my alma mater, where I graduated in 1992. NCSSM is a public residential high school in which students attend their junior and senior years, and of course as the name suggests has an emphasis on science and math curriculum (but it is so much more than that). For some reason, the students and administrators asked me to give the commencement address this year, which is one of the strangest things I've ever had to do -- in part because it felt like yesterday that I graduated from there (yet it was 22 years ago)!

NCSSM is dear to my heart and those two years were a transformative time in my life. I've blogged before about how my time at S&M saved my life -- it is difficult to overstate how important the place was to my formative years. (Actually I think I'm still "forming".)

I wore Google Glass to give the speech, thinking this would be a really cool and unique way to show off my "Google-ness", but actually one of the graduating seniors was wearing Glass as well:

So much for being unique.

The school live-streamed the event and I was surprised to find a video of my speech online soon after it was over. Watch here at your own peril.

Below I'm posting my prepared speech (which is not exactly the same as the one I actually gave).

Students, professors, parents, mom, (hi mom!), it is most humbling to stand before you here today. Indeed, I am terrified. Somehow I think I am being punished for all of the misdeeds I was involved with back during my days as a student here so many years ago. Either that, or the fact that I am here must be proof that there is no such thing as a permanent record -- if they had one on me, well, let’s just say they would have thought twice about inviting me back to give a commencement address. So, those of you who stayed out way too late last night -- there is hope for you yet! 

Before we begin, I want to get one thing out of the way. Some of you may be wondering what this thing is that I’m wearing. This is called Google Glass, and basically, it’s a cell phone that you strap to your head. I am told that in some neighborhoods of San Francisco it either makes you utterly irresistible to the opposite sex, or it gets you beat up. Google Glass has all kinds of amazing features, and this little screen up here is feeding me a constant stream of information about each and every one of you … yes, you in the back there… the one who made a B-minus in history last term… Google Glass is telling me that those tennis shoes you ordered off of Amazon last week will be delivered this afternoon. You’re welcome.

It’s really remarkable to be back here, twenty-two years after I graduated from NCSSM, on this very lawn. Of course, I don’t remember much about the graduation ceremony itself, seeing as how I got absolutely no sleep the night before. You see, I stayed up too late with my friends and staggered back to my room at 5 o’clock in the morning and realized I had not started packing my room. At all. And my parents were arriving in just a few short hours, expecting me to be rested, cheery, but most of all packed and ready to go. So I frantically threw everything I owned into boxes, tore all of the Depeche Mode posters off of the walls, packed away my IBM PC and boxes full of diskettes, and tried to make some order out of chaos. I was only partially successful, but my parents understood, and we loaded everything into the minivan, and away we went. Sorry, mom! You guys were great about it though.

Poof. Just like that, my NCSSM experience was over. They really were two of the best years of my life, in so many ways -- and the experiences I had here utterly changed the course of my life. I am sure most of you feel the same way already, but the ripple effect will be felt for years to come. Look around -- look at your friends, your teachers, your RAs. This place has made a deep and enduring mark on who you are and who you will be.

NCSSM taught me the single most important lesson I’ve ever learned in my life, and I want to share it with you.

It’s very simple: Never stop looking. That is, never stop looking for who you are, where you belong, and what you might do with your short time on this planet. Sometimes it takes a really, really big change to figure that out.

Before coming to S&M -- as we called it affectionately in those days -- I grew up in a small town called Wilson, about an hour east of here. I cannot say that I really loved Wilson, and I didn’t fit in well there at all. For one thing, I didn’t have a car, so I could not join the legions of kids who would spend their Friday nights driving in circles around the mall, which was pretty much the only entertainment there. But more than that, with the exception of a few close friends, I never quite felt like I found kindred spirits -- people with the same weird and geeky interests that I had. People who saw the world in the same way.

Fortunately, I was admitted to Science and Math, and I am dead serious when I say that coming here saved my life. Almost as soon as I arrived here, I realized that I had found what I had been looking for all of those years in Wilson, where I was so out of place -- people who cared about the same things that I did. People who were smarter, and weirder, and more interesting than I could ever be. Teachers with an amazing passion and ability to inspire. A cafeteria serving the most amazing food … wait … scratch that … The food was terrible. But at least it was free!

Coming to Science and Math was the first time that I realized that there was a bigger, more incredible, more inspiring world out there than the narrow confines of my experience back in Wilson. I am sure many of you have had the same experiences, over and over again while roaming these halls. Never forget it. It’s the most important thing you can take away from your time here.

This lesson has been reinforced many times in my life. Another time was my first opportunity to travel outside of the developed world. Although I had traveled and lived in Europe during college, it wasn’t until I was a grad student at Berkeley that my wife and I traveled to “difficult” places -- the first such trip being Nepal, where we spent about a month, trekking through the Himalaya. I will never forget the experience of arriving in Kathmandu for the first time, speeding through the night in a taxi, looking out at the eye-popping poverty, the people everywhere, cows and goats and water buffalo roaming in the road, the endless cars and rickshaws and bicycles and motor scooters everywhere -- it might has well have been a different planet. It completely changed my conception of what the world was like, right there, over the course of about ten minutes.

Over the following years, we traveled to many other places as remote as Papua New Guinea, Bolivia, and Laos -- and every time my mind was blown by how strange and big and varied the world is. If I can leave you all with just one thing from today, it would be to encourage you to travel the world. Especially while you are young. Not enough young people do this, and I think it’s the single most effective way to broaden your horizons in life.

I also learned this lesson when I decided to quit my job as a professor at Harvard to join Google. To many people, being a professor, especially somewhere like Harvard, sounds like a dream job. You get tremendous freedom, the opportunity to work with some of the smartest students and faculty anywhere. Mark Zuckerberg, the founder of Facebook, was even one of my students. If you’ve seen the movie “The Social Network”, that scene where Zuck storms out of a Computer Science lecture -- the professor in that scene was supposed to be me -- those were in fact my real PowerPoint slides from class! Of course Mark never stormed out of a lecture -- he wasn’t actually in lecture often enough for that to have happened.

The thing is, being a professor is really, really hard work. You have almost no down time, as there’s always another deadline, another lecture to prepare, another letters to write. It’s grueling. Your teachers here have to work just as hard, so you should really thank them today -- they work their tails off for you.

So after seven years at Harvard, I was ready for a change, and started a sabbatical at Google. And going to Google felt a heck of a lot like what it felt coming to Science and Math for the first time. I mean, nerds everywhere! People wearing socks with sandals! The other day, I went to a meeting, and one of the engineers actually had a live parrot on his shoulder. This is totally normal at Google! And, just like Science and Math, they even have free food! Though you don’t have to work in the cafeteria or rake pine needles. That part’s much better.

I knew almost from the moment I went to Google that that was where I was meant to be -- that I had found my kin. But it took making a big change -- giving up a permanent job, leaving behind my students and colleagues, moving my family across the country -- to figure that out. So it was a big risk, but the reward was huge -- finding out what I really want to be doing with my life, right now. You have to take those risks.

So never stop looking. That’s it. Pretty simple, right? Never stop looking. You never know what you might find.

And with that, I just want to say, congratulations to you all. Today is a big day -- it’s your day. Live it up! Don’t forget it! That is, if you got any sleep last night. If you didn’t, well, you can go back to sleep now because the best part is over.

Thank you very much, and congratulations to the class of 2014!

The Google career path, Part 2: Starting new projects

In my last blog post, I talked about what it's like to get started at Google as a new engineer. In this post, I'll talk about how new projects get started.

Standard disclaimer applies: This is my personal blog and nothing I'm saying here is endorsed or approved by Google. This is only based on my personal experience. Take it with a grain of salt.

Google is well known as having a bottom-up engineering culture. That is, new projects typically arise because a group of engineers get together, decide a problem needs to be solved, devise a solution, and convince others to (a) join in the effort and (b) launch it. It is rare -- although not unheard of -- for a Google project to start with a high-level mandate from some executive. (I have heard that this is how Google+ got its start, but I wasn't there at the time, so I don't really know.) More typically, a grassroots effort emerges out of engineers trying to build something that they think is important and will change the world. Or at least scratch an itch.

How my project got its start

My team is responsible for a range of projects to optimize and streamline the mobile web. The main thing we are known for is the Chrome Mobile data compression proxy, which provides users of Chrome on Android and iOS a switch they can flip in the browser to compress web pages by 50%. I thought it might be instructive to talk about how this project came about.

When I started the team in 2011, I was given a very broad mandate: Go fix the mobile web. Initially, we spent a bunch of time just trying to understand the problem. At the time, there were no good tools for even measuring mobile web page performance. Now, we have things like Webpagetest for mobile, but at the time you couldn't get decent measurements without a lot of work. So, we built a testbed for collecting mobile web measurements and bought a bunch of phones and tablets and started collecting data. We spent a huge amount of time analyzing the data and playing around with various technologies, like PageSpeed, to see what kind of gains could be had.

At one point we realized that the only way to move the needle with mobile web performance was to build our own proxy service which could be integrated into a browser. Around the same time, the Chrome Mobile project was ramping up, and we realized that the technology we were building would be a great addition to Chrome when it became available for Android and iOS. So, we went to the Chrome team (which we were not yet a part of) and pitched the idea -- would it make sense to integrate this hypothetical proxy into the browser, provide a setting for users to enable it? At the time, we didn't even have the proxy yet -- just a slide deck and a crude, proof-of-concept demo. But we had a lot of ideas of what it could do and how it would work.

Fortunately, the Chrome team loved the idea and even offered to take our team on as part of the Chrome project. Of course, they hadn't agreed to launch anything yet -- that approval wouldn't come until many months later -- but we had their blessing to develop the idea further and get it to a state where it could be dogfooded within Google. So we built it. We got it to dogfood. We collected data from real users (well, Googlers anyway). The data looked good, so we got approval to launch it externally, first behind a flag, then in the Chrome beta channel, and finally launch it to everyone. Boom!

So the idea for the proxy service and the project as a whole came entirely from within our team. Nobody told us to do this. And it was our job to "sell" it internally, in terms of turning the idea into a fully-baked feature that could launch with Chrome. In a lot of ways, it's like being a startup company (although one that does not have to worry about funding and already has fancy cafeterias and a gym).

Does this generalize?

I can't say for certain that my experience is the standard way of getting new projects off the ground at Google, but it seems to be.

Projects often seem to get their start with one or two engineers who have an itch to scratch, and come up with something compelling that they want to build. They might start the project on their own, in their 20% time (on which see more below), or they might spawn an effort out of their existing work.

A typical example might be where an engineer realizes that a new system needs to be built to solve a problem that they keep running into all the time (measuring mobile web pages, say). So with the blessing of their manager (or not, in some cases), they carve out time to get that project off the ground. If it's successful, it might grow, and more engineers will start to get involved.

New projects often die, too. Sometimes a project will start out with a couple of people, they'll spend a quarter or two trying to get it off the ground, and the effort fizzles out for any number of reasons. One example is that it turns out to be much harder than expected. Another is that other priorities come up and they don't have the time to run as far with the idea as they had hoped. Another is that some other project comes along which is a broader, more general form of what they were trying to do, so they decide to join forces (or just shut down the original effort).

What about 20% time?

Much has been written about Google's "20% time", whereby engineers are allowed to work on projects unrelated to their main job. (You can't do just anything for 20% projects -- taking guitar lessons wouldn't be allowed, for example -- but the definition is pretty broad.) 20% projects are a great way to seed a new effort, since (a) you don't really need any formal approval to work on them, and (b) it gives engineers a chance to do things that they would not otherwise find the time to do.

Gmail famously started as a 20% project. (The original press release was ironically posted on April 1, 2004, but it was not actually an April Fools' joke!)

There have also been many unfounded rumors of 20% time's demise. From where I sit, 20% time is alive and well, and several engineers on my team have active 20% projects. For example, one of them contributes actively to our internal platform for employees making charitable contributions, called "G-Give". Another contributes to the smart contact lens project. My own (unofficial) 20% project is doing outreach activities to the Computer Science research community -- serving on program committees, reviewing research proposals, that kind of thing. (It actually takes a lot less than 20% of my time, but don't tell my boss that.)

That said, 20% time is not used uniformly across the company and some managers are probably allergic to it. I don't think all engineers should do 20% projects, since often people can have more impact if they spend 100% of their time on their "day job" -- the 20% would be a distraction and not necessarily help them get promoted.

But promotions are the subject of my next blog post, so I'll leave it at that.

The Google career path, part 1: Getting started

Apart from how to get a job at Google (which I have previously blogged about), the most common question I get from people considering taking a job here is what the career path is like -- that is, how you get started, how you grow your career, how promotions work, and so forth. I thought I'd try to capture some of my perspective in a series of blog posts on the topic.

(But first, the obligatory disclaimer: This is my personal blog. Google doesn't condone or support anything I'm saying here. Heck, it's probably all wrong anyway. Take it with a grain of salt.)

This stuff is mostly targeted at new grad hires (at any level -- Bachelors, Masters, or PhD) for software engineering positions. (I don't know how things work in other parts of the company, like sales.) This may apply to a lesser extent to more senior engineers or researchers as well.

Before you join: The team match

Before your start date, you will be assigned to one of the many hundreds of teams at Google. While there are exceptions, teams typically consist of O(10) people who all report to the same manager and have a common project focus. Examples might include the Android Hangouts app, feeding real-time data such as sports scores into Search, or (my team) making mobile Web browsing faster and more efficient.

A lot of people want to work on teams doing things they have already heard of -- such as Search, Chrome, or Android. But keep in mind that the vast majority of teams at Google work on things that are (a) not user-facing and therefore (b) not something you would necessarily know anything about before coming here. My first team at Google focused our content delivery network for YouTube, which I never even knew existed until I started the job. Many project teams are building internal infrastructure and tools, and often the work they do is highly confidential, so we can't (unfortunately) always tell new hires very much about the details of what the team works on until they join.

Google tries to assign you to a team that matches your interests. If you are a Bachelors or Masters new grad hire, the team match is typically done in a "late binding" fashion, a few weeks before the start date (so, after you have accepted the job offer). Given how rapidly projects and hiring priorities shift among teams, it makes sense to do the binding as late as possible. For PhD and more senior candidates, because your skills are more specialized, the recruiters try to make sure that the candidate has a team interested in hiring you even before bringing you in for an interview. As a result, you essentially have a spot "reserved" on that team well before you would begin the job. In those cases you might be able to learn a bit more about what your target team is working on during the process of interviewing and negotiating the offer.

The thing I always emphasize is that when you are hired by Google, you are getting a job at Google, not a specific team at Google. In other words, the initial team match is by no means final, and nor is it locking you down. Engineers move between teams all the time -- it is not uncommon for people to look for a new team every couple of years. Some people prefer the stability of staying in the same area year after year, while others prefer to explore different parts of the company. New projects and teams are always spinning up, and (indeed) teams often reorganize or disband. So there is a fair bit of churn, and I would not stress the initial team assignment much -- it's a starting point.

The starter project

My advice to people starting at Google is to roll up your sleeves, dive in, and start contributing however you can. It's a super steep learning curve, and for the first month or two you won't have the foggiest idea what anybody is talking about, but the more you get involved the faster you'll come up to speed.

The first week on the job is typically spent in orientation, which is usually done at the headquarters in Mountain View. I blogged about my first week at Google a while back -- it is pretty intense, and there is a huge amount to learn. I found it to be super fun (though exhausting) and have great memories of that week. You get your badge, your laptop, your first five or six items of Google schwag, try to figure out where to get lunch, how the videoconference system works, and how to get started on programming in our insanely complex environment. There are a bunch of hour-long courses on topics ranging from how Google Search works to how to use our source code control system.

After the first week you'll start working with your new team. Your starter project is intended to show you the ropes and get you up to speed on our coding environment, build tools, code review process, and so forth, so you can start to be a fully productive member of the team. Starter projects might be something like adding a small feature to your team's code or fixing a straightforward bug. A starter project might take anywhere from a week to a month.

Taking ownership

As you come up to speed, you'll proceed to taking on projects with larger complexity and scope, as you become more familiar with the codebase and conversant in the problems that are being worked on by your team. It's really up to you to drive this process and own your work.

To give a concrete example, one of the (relatively) recent PhD hires on my team, Michael Buettner, started out by investigating the size and quality tradeoff for the image transcoding parameters we were using in the Chrome Mobile data compression proxy. Over time he expanded his expertise of our software and started taking on harder, bigger problems -- including sophisticated optimizations to the proxy's HTTP fetching backend. He is now our team's "latency expert" and has devoted a great deal of his time to making the whole system faster. Since he knows so much of our codebase, he advises on a broad range of new features and bugfixes, and works with other teams to implement functionality to streamline our system's performance.

I want to emphasize that this is not something Michael was specifically tasked with doing. Like most teams, ours has way more problems than people, so engineers tend to gravitate towards the problems that match their interests. My job as the team lead is to coordinate and prioritize our team's work, and fortunately we rarely have cases where we have something really important to do that's not up someone's alley.

In the next couple of blog posts I'll talk about the evaluation and promotion process at Google, as well as how new projects are started.