tag:blogger.com,1999:blog-91864572424283351442024-03-15T01:05:22.139-07:00Volatile and DecentralizedMatt Welshhttp://www.blogger.com/profile/04255792550910131960noreply@blogger.comBlogger168125tag:blogger.com,1999:blog-9186457242428335144.post-40813497555303272602019-06-12T08:47:00.001-07:002019-06-12T08:47:48.398-07:00Startup Life: Three Months In<div dir="ltr" style="text-align: left;" trbidi="on">
I've posted a story to Medium on what it's been like to work at a startup, after years at Google. <a href="https://medium.com/@mdwdotla/startup-life-three-months-in-a6b9a494b00b?source=friends_link&sk=82bb8863ddd0032cf8cfd925b76559cc">Check it out here.</a></div>
Matt Welshhttp://www.blogger.com/profile/16775626886980707410noreply@blogger.com0tag:blogger.com,1999:blog-9186457242428335144.post-37189810534248497732019-02-23T09:53:00.000-08:002019-02-23T09:53:50.677-08:00Thoughts on running successful software teams at Google<div dir="ltr" style="text-align: left;" trbidi="on">
Check out my recent blog post on Medium on some of the principles I have adopted to help teams be successful.<br />
<br />
<a href="https://medium.com/@mdwdotla/some-thoughts-on-running-successful-teams-at-google-c06124959205">https://medium.com/@mdwdotla/some-thoughts-on-running-successful-teams-at-google-c06124959205</a><br />
<br /></div>
Matt Welshhttp://www.blogger.com/profile/16775626886980707410noreply@blogger.com0tag:blogger.com,1999:blog-9186457242428335144.post-47195545085889211032019-02-11T10:19:00.005-08:002019-02-11T10:19:37.880-08:00Why I'm leaving Google for a startup<div dir="ltr" style="text-align: left;" trbidi="on">
After more than eight years at Google, I'm joining <a href="http://xnor.ai/">XNOR.ai</a>, a small startup developing AI for embedded devices.<br />
<br />
Check out <a href="https://medium.com/@mdwdotla/why-im-leaving-google-for-a-startup-88be418236d8">my blog post on Medium here</a>.<br />
<br /></div>
Matt Welshhttp://www.blogger.com/profile/16775626886980707410noreply@blogger.com1tag:blogger.com,1999:blog-9186457242428335144.post-26832964732908072282019-02-06T10:21:00.004-08:002019-02-06T10:21:39.517-08:00Over-the-Air Arduino firmware updates using Firebase, Part 1<div dir="ltr" style="text-align: left;" trbidi="on">
Just a reminder that I'm blogging on <a href="https://medium.com/@mdwdotla">Medium</a> these days.<br />
<br />
I just posted another article, this time on using Firebase to support over-the-air firmware updates for Arduino projects. <a href="https://medium.com/@mdwdotla/over-the-air-arduino-firmware-updates-using-firebase-part-1-3e874ad9f93e">Check it out!</a><br />
<br /></div>
Matt Welshhttp://www.blogger.com/profile/16775626886980707410noreply@blogger.com0tag:blogger.com,1999:blog-9186457242428335144.post-36939079718793844992019-02-03T20:29:00.003-08:002019-02-03T20:29:20.756-08:00I'm blogging on Medium!<div dir="ltr" style="text-align: left;" trbidi="on">
Hey folks! If you're reading this blog, you may be in the wrong place.<br /><br />
I've decided to try out Medium as a new blogging platform.<br />
<br />
Check out my <a href="https://medium.com/@mdwdotla">Medium blog here</a>!<br />
<br />
So far, I have one article posted: <b><a href="https://medium.com/@mdwdotla/using-firebase-to-control-your-arduino-project-over-the-web-ba94569d172c">Using Firebase to Control your Arduino Project over the Web</a>. </b>Hopefully more to come soon.<br />
<br />
<br /></div>
Matt Welshhttp://www.blogger.com/profile/16775626886980707410noreply@blogger.com0tag:blogger.com,1999:blog-9186457242428335144.post-24299555757479042902016-06-07T13:17:00.002-07:002016-06-07T13:17:32.000-07:00Death by peer review<div dir="ltr" style="text-align: left;" trbidi="on">
I recently had the occasion to give some advice a friend who was considering making the switch from industry to academia. One of my key pieces of advice was to keep in mind that success (or failure) in academia is largely based on peer review -- by program committees, proposal review panels, tenure committees. While peer review has many good things going for it, it can also be extremely, dishearteningly random. Being an academic means living your life one peer-review decision to the next, and in many cases, those decisions are simply not the right ones. After a while, a string of semi-random decisions can be psychologically draining.<br /><br /><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://2.bp.blogspot.com/-AgWm50Gjxac/V1cqiy0TVeI/AAAAAAACLSo/_5yi7R1J9BcT4tfMdc_VBdjysrh7lb-lQCLcB/s1600/YHDOPR-copy.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="200" src="https://2.bp.blogspot.com/-AgWm50Gjxac/V1cqiy0TVeI/AAAAAAACLSo/_5yi7R1J9BcT4tfMdc_VBdjysrh7lb-lQCLcB/s400/YHDOPR-copy.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">From <a href="http://www.michaeleisen.org/blog/?p=1778">http://www.michaeleisen.org/blog/?p=1778</a>. Yes, I own the t-shirt.</td></tr>
</tbody></table>
The law of large numbers certainly applies here. Good work eventually gets published and funded, given enough iterations. Good researchers get their papers in, eventually. Peer review feedback can be incredibly helpful for refining a piece of work and improving it over time. But in the vast majority of cases, papers or proposals, whether accepted or rejected in the end, get a wide range of scores -- it is quite rare for even a good paper to get all "accept" reviews. Whether a paper gets accepted often depends on who the reviewers are, whether they've had enough coffee in the PC meeting, whether they are confident enough to stand up for the work, and so forth. Above a certain threshold, the objective merit of the work has little to do with the outcome.<br /><br />This situation can get really bad. <a href="http://matt-welsh.blogspot.com/2010/05/proposal-improving-nsf-review-process.html">NSF proposal reviews</a> are, historically, quite random, in part because NSF's conflict-of-interest policy prevents anyone who might actually be an expert in the area from reviewing your work (unless they forgot to submit their own proposal). I have submitted substantially the same NSF proposal multiple times and had vastly different scores. My best proposal never got funded; my worst proposal actually did. <br /><br />To be clear, <a href="https://www.quora.com/What-is-the-promotion-process-like-at-Google">we also use peer review at Google</a>, in particular for things like promotions. I've served on quite a few promotions committees, and I can tell you it can be just as random as, say, a conference program committee. Get four people into a room and they will have four different opinions about a given candidate. So I don't think this problem is specific to the academic peer review process.<br /><br />But I want to contrast the peer-review process with the "industry process." At least at Google, I feel that hard work is generally rewarded if it has impact and leads to good products. My expectation is that the same is true at most companies. Rather than the success or failure of a project coming down to the dreaded Reviewer #3, it comes down to the team's ability to execute, targeting the right market, and attracting users.<div>
<br /></div>
<div>
Of course, many of these factors are just as out of the control of an engineer on the team as the capriciousness of a program committee. However, I believe the industry process is <i>far less arbitrary</i>. Yes, projects can (and do) get canceled by higher-level management. I've personally canceled projects on my teams, for a range of reasons. But the reasons for project cancellation are, in most cases, made after careful deliberation and by people who have a vested interest in the team. Even if the decision ends up being wrong, at least it's a decision that <i>makes sense</i> -- not the crapshoot you face every time you submit a paper or proposal to a random committee.<br /><br />Do companies make bad decisions? Absolutely. Are decisions made that I personally disagree with? Of course. Do I have to work for a company that continually makes bad decisions that I don't agree with? Hell no. I'd much rather face my chances against a principled leadership organization that I trust and agree with than an ad hoc collection of anonymous reviewers.<br /><br />While I have many thoughts on how the process of peer review could be improved, I don't argue that we should dispense with it entirely. I don't know of a better model for most things that academics need to be evaluated on. But aspiring academics should how much of your success hinges on the purely stochastic nature of the process. Industry is still a game, but it's a different kind of game, and one that I think tends to be more rational.<div>
<br /></div>
</div>
</div>
Unknownnoreply@blogger.com12tag:blogger.com,1999:blog-9186457242428335144.post-69645053532427333592016-04-25T22:40:00.002-07:002016-04-25T22:40:24.511-07:00Why I gave your paper a Strong Accept<div dir="ltr" style="text-align: left;" trbidi="on">
See also: <a href="http://matt-welsh.blogspot.com/2016/04/why-i-gave-your-paper-strong-reject.html">Why I gave your paper a Strong Reject</a><br />
<br />
I know this blog is mostly about me <a href="http://matt-welsh.blogspot.com/2016/01/academics-we-need-to-talk.html">complaining</a> <a href="http://matt-welsh.blogspot.com/2013/05/what-i-wish-systems-researchers-would.html">about</a> <a href="http://matt-welsh.blogspot.com/2016/01/academics-we-need-to-talk.html">academics</a>, but there's a reason I stay engaged with the research community: I learn stuff. Broadly speaking, I think it's incredibly important for industry to both stay abreast of what's going on in the academic world, as well as have some measure of influence on it. For those reasons, I serve on a few program committees a year and do other things like help review proposals for Google's <a href="http://research.google.com/research-outreach.html#/research-outreach/faculty-engagement/faculty-research-awards">Faculty Research Award</a> program.<br />
<br />
Apart from learning new things, there are other reasons to stay engaged. One is that I get a chance to meet and often work with some incredible colleagues, either professors (to collaborate with) or students (to host as interns and, in many cases, hire as full-time employees later on).<br />
<br />
I also enjoy serving on program committees more than just going to conferences and reading papers that have already been published. I feel like it's part of my job to give back and contribute my expertise (such as it is) to help guide the work happening in the research community. Way too many papers could use a nudge in the right direction by someone who knows what's happening in the real world -- as a professor and grad student, I gained a great deal from my interactions with colleagues in industry.<br />
<br />
Whenever I serve on a program committee, I make it a point to champion at least a couple of papers at the PC meeting. My colleagues can attest to times I've (perhaps literally) pounded my fist on the table and argued that we need to accept some paper. So to go along with my <a href="http://matt-welsh.blogspot.com/2016/04/why-i-gave-your-paper-strong-reject.html">recent post</a> on why I tend to mark papers as reject, here are some of the reasons that make me excited to give out a Strong Accept.<br />
<br />
(Disclaimer: This blog represents my personal opinion. My employer and my dog have nothing to do with it. Well, the dog might have swayed me a little.)<br />
<br />
<b>The paper is perfect and flawless.</b> Hah! Just kidding! This never happens. No paper is ever perfect -- far from it. Indeed, I often champion papers with significant flaws in the presentation, the ideas, or the evaluation. What I try to do is decide whether <b>the problems can be fixed through shepherding</b>. Not everything can be fixed, mind you. Minor wording changes or a slight shift in focus are fixable. Major new experiments or a total overhaul of the system design are not. When I champion a paper, I only do so if I'm willing to be on the hook to shepherd it, should it come to that at the PC meeting (and it often does).<br />
<br />
<b>Somebody needs to stand up for good papers. </b>Arguably, no paper would ever get accepted unless some PC member were willing to go to bat for it. Sadly, it's a lot easier for the PC to find flaws in a paper (hence leading to rejection) than it is to stand up for a paper and argue for acceptance -- <i>despite the paper's flaws. </i>Every PC meeting I go to, someone says, "This is the best paper in my pile, and we should take it -- that's why I gave it a weak accept." Weak accept!?!? WEAK!?! If that's the best you can do, you have no business being on a program committee. Stand up for something.<br />
<br />
In an effort to balance this out, I try to take a stand for a couple of papers every time I go to a PC meeting, even though I might not be successful in convincing others that those papers should be accepted. Way better than only giving out milquetoast scores like "weak accept" or -- worse -- the cop-out "borderline".<br />
<br />
<b>The paper got me excited.</b> This is probably the #1 reason I give out Strong Accepts. When this happens, usually by the end of the first page, I'm getting excited about the rest of the paper. The problem sounds compelling. The approach is downright sexy. The summary of results sound pretty sweet. All right, so I'm jazzed about this one. Sometimes it's a big letdown when I get into the meat and find out that the approach ain't all it was cracked up to be in the intro. But when I get turned on by a paper, I'll let the small stuff slide for sure.<br />
<br />
It's hard to predict when a paper will get me hot under the collar. Sometimes it's because the problem is close to stuff I work on, and I naturally gravitate to those kinds of papers. Other times it's a problem I really wish I had solved. Much of the time, it's because the intro and motivation are just really eloquent and convincing. The quality of writing matters a lot here.<br />
<br />
<b>I learned a lot reading the paper.</b> Ultimately, a paper is all about what the reader takes away from it. A paper on a topic slightly out of my area that does a fine job explaining the problem and the solution is a beautiful thing. Deciding how much "tutorial" material to fit into a paper can be challenging, especially if you're assuming that the reviewers are already experts in the topic at hand. But more often than not, the PC members reading your paper might not know as much about the area as you expect. Good exposition is usually worth the space. The experts will skim it anyway, and you might sell the paper to a non-expert like me.<br />
<br />
<b>There's a real-world evaluation.</b> This is not a requirement, and indeed it's somewhat rare, but if a paper evaluates its approach on anything approximating a real-world scale (or dataset) it's winning major brownie points in my book. Purely artificial, lab-based evaluations are more common, and less compelling. If the paper includes a real-life deployment or retrospective on what the authors learned through the experience, even better. Even papers without that many "new ideas" can get accepted if they have a strong and interesting evaluation (<a href="http://www.mdw.la/papers/volcano-osdi06.pdf">cough</a> <a href="http://www.mdw.la/papers/flywheel-nsdi15.pdf">cough</a>).<br />
<br />
<b>The paper looks at a new problem, or has a new take on an old problem.</b> Creativity -- either in terms of the problem you're working on, or how you approach that problem -- counts for a great deal. I care much more about a creative approach to solving a new and interesting (or old and hard-to-crack) problem than a paper that is thoroughly evaluated along every possible axis. Way too many papers are merely incremental deltas on top of previous work. I'm not that interested in reading the <i>Nth</i> paper on time synchronization or multi-hop routing, unless you are doing things <i>really</i> differently from how they've been done before. (If the area is well-trodden, it's also unlikely you'll convince me you have a solution that the hundreds of other papers on the same topic have failed to uncover.) Being bold and striking out in a new research direction might be risky, but it's also more likely to catch my attention after I've reviewed 20 papers on less exciting topics.<br />
<br />
<br /></div>
Unknownnoreply@blogger.com1tag:blogger.com,1999:blog-9186457242428335144.post-78575905701045204432016-04-20T22:38:00.001-07:002016-04-25T22:43:30.595-07:00Why I gave your paper a Strong Reject<div dir="ltr" style="text-align: left;" trbidi="on">
Also see: <a href="http://matt-welsh.blogspot.com/2016/04/why-i-gave-your-paper-strong-accept.html">Why I gave your paper a Strong Accept</a>.<br />
<br />
I'm almost done reviewing papers for another conference, so you know what that means -- time to blog.<br />
<br />
I am starting to realize that trying to educate individual authors through my witty and often scathing paper reviews may not be scaling as well as I would like. I wish someone would teach a class on "How to Write a Decent Goddamned Scientific Paper", and assign this post as required reading. But alas, I'll have to make do with those poor souls who stumble across this blog. Maybe I'll start linking this post to my reviews.<br />
<br />
All of this has probably been said before (<i>strong reject</i>) and possibly by me (<i>weak accept?</i>), but I thought I'd share some of the top reasons why I tend to shred papers that I'm reviewing.<br />
<br />
(Obligatory disclaimer: This post represents my opinion, not that of my employer. Or anyone else for that matter.)<br />
<div>
<br /></div>
<b>The abstract and intro suck.</b> By the time I'm done reading the first page of the paper, I've more or less decided if I'm going to be reading the rest in a positive or negative light. In some cases, I won't really read the rest of the paper if I've already decided it's getting The Big SR. Keep in mind I've got a pile of 20 or 30 other papers to review, and I'm not going to spend my time picking apart the nuances of your proofs and evaluation if you've bombed the intro.<br />
<br />
Lots of things can go wrong here. Obvious ones are pervasive typos and grammatical mistakes. (In some cases, this is tolerable, if it's clear the authors are not native English speakers, but if the writing quality is <i>really</i> poor I'll argue against accepting the paper even if the technical content is mostly fine.) A less obvious one is not clearly summarizing your approach and your results in the abstract and intro. Don't make me read deep into the paper to understand what the hell you're doing and what the results were. It's not a Dan Brown novel -- there's no big surprise at the end.<br />
<br />
The best papers have really eloquent intros. When I used to write papers, I would spend far more time on the first two pages than anything else, since that's what really counts. The rest of the paper is just backing up what you said there.<br />
<br />
<b>Diving into your solution before defining the problem.</b> This is a huge pet peeve of mine. Many papers go straight into the details of the proposed solution or system design before nailing down what you're trying to accomplish. At the very least you need to spell out the goals and constraints. Better yet, provide a realistic, concrete application and describe it in detail. And tell me why previous solutions don't work. In short -- motivate the work.<br />
<br />
<b>Focusing the paper on the mundane implementation details, rather than the ideas.</b> Many systems papers make this mistake. They waste four or five pages telling you all about the really boring aspects of how the system was implemented -- elaborate diagrams with boxes and arrows, detailed descriptions of the APIs, what version of Python was used, how much RAM was on the machine under the grad student's desk.<br />
<br />
To first approximation, I don't care. What I do care about are your ideas, and how those ideas will translate beyond your specific implementation. Many systems people confuse the artifact with the idea -- <a href="http://matt-welsh.blogspot.com/2011/11/software-is-not-science.html">something I have blogged about before</a>. There <i>are</i> papers where the meat is in the implementation details -- such as how some very difficult technical problem was overcome through a new approach. But the vast majority of papers, implementation doesn't matter that much, nor should it. Don't pad your paper with this crap just to make it sound more technical. I know it's an easy few pages to write, but it doesn't usually add that much value.<br />
<br />
<b>Writing a bunch of wordy bullshit that doesn't mean anything.</b> Trust me, you're not going to wow and amaze the program committee by talking about dynamic, scalable, context-aware, Pareto-optimal middleware for cloud hosting of sensing-intensive distributed vehicular applications. If your writing sounds like the <a href="https://pdos.csail.mit.edu/archive/scigen/rooter.pdf">automatically-generated, fake Rooter paper</a> ("A theoretical
grand challenge in theory is the important unification
of virtual machines and real-time theory. To what extent can
web browsers be constructed to achieve this purpose?"), you might want to rethink your approach. Be concise and concrete. Explain what you're doing in clear terms. Bad ideas won't get accepted just because they sound fancy.<br />
<br />
<b>Overcomplicating the problem so you get a chance to showcase some elaborate technical approach.</b> A great deal of CS research starts with a solution and tries to work backwards to the problem. (I'm as guilty of this, too.) Usually when sitting down to write the paper, the authors realize that the technical methods they are enamored with require a contrived, artificial problem to make the methods sound compelling. Reviewers generally aren't going to be fooled by this. If by simplifying the problem just a little bit, you render your beautiful design unnecessary, it might be time to work on a different problem.<br />
<br />
<b>Figures with no descriptive captions.</b> This is a minor one but drives me insane every time. You know what I mean: A figure with multiple axes, lots of data, and the caption says "Figure 3." The reviewer then has to read deep into the text to understand what the figure is showing and what the take-away is. Ideally, figures should be self-contained: the caption should summarize both the content of the figure and the meaning of the data presented. Here is an example from <a href="http://www.mdw.la/papers/mercury-sensys09.pdf">one of my old papers</a>:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://4.bp.blogspot.com/-_4QFaaHWlGo/VxhkIdS6HXI/AAAAAAACLD8/bmxvaUtQbMkO17PTPAcgCnzpIsqSKIw7gCLcB/s1600/Screen%2BShot%2B2016-04-20%2Bat%2B10.24.05%2BPM.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="284" src="https://4.bp.blogspot.com/-_4QFaaHWlGo/VxhkIdS6HXI/AAAAAAACLD8/bmxvaUtQbMkO17PTPAcgCnzpIsqSKIw7gCLcB/s320/Screen%2BShot%2B2016-04-20%2Bat%2B10.24.05%2BPM.png" width="320" /></a></div>
<br />
Isn't that beautiful? Even someone skimming the paper -- an approach I do <i>not</i> endorse when it comes to my publications -- can understand what message the figure is trying to convey.<br />
<br />
<b>Cursory and naive treatment of related work.</b> The related work section is not a shout-out track on a rap album ("This one goes out to my main man, the one and only Docta Patterson up in Bezerkeley, what up G!"). It's not there to be a list of citations just to prove you're aware of those papers. You're supposed to discuss the related work and place it in context, and contrast your approach. It's not enough to say "References [1-36] also have worked on this problem." Treat the related work with respect. If you think it's wrong, say so, and say why. If you are building on other people's good ideas, give them due credit. As my PhD advisor used to tell me, stand on the shoulders of giants, not their toes.<br />
<br /></div>
Unknownnoreply@blogger.com11tag:blogger.com,1999:blog-9186457242428335144.post-41465114836243934542016-03-02T23:11:00.000-08:002016-03-02T23:11:26.784-08:00Everything I did wrong as a professor<div dir="ltr" style="text-align: left;" trbidi="on">
I really screwed things up as a young faculty member at Harvard. It worked out OK in the end, but, man, I wish I could go back in time to when I was a new professor and give my younger self some much-needed advice. No, not the "you shouldn't be a professor, get another kind of job" advice -- I wouldn't have listened to that -- but one of the reasons I ended up leaving academia is that I burned myself out. Maybe that could have been avoided had I taken a different approach to the job.<br />
<br />
What did I get wrong? Let me count the ways...<br />
<br />
<b>Working on too many projects at once.</b> I thrive on having many balls in the air. As a junior faculty member, though, I probably should have stayed focused on just one or two juicy projects, and let all the others fall to the side. I did not have a good filter for thinking about which projects I should take on and where they might lead. It was difficult to say no to any new research direction, since for all I knew it might lead somewhere great.<br />
<br />
This one is tricky. When I first heard about using sensor networks to <a href="http://www.mdw.la/papers/volcano-osdi06.pdf">monitor volcanic eruptions</a>, I thought it was a terrible idea and unlikely to lead anywhere. It turned out to be one of my most exciting and productive projects. So what the hell do I know?<br />
<br />
<b>Taking on high-risk projects with factors out of my control.</b> Managing risk was not something I spent much time thinking about. I worked hard to build collaborations with the medical community to use sensor networks for things like disaster triage and <a href="http://www.mdw.la/papers/parkinsons-titb09.pdf">monitoring patients with Parkinson's Disease</a>. The volcano monitoring project also had a tremendous amount of risk (not just that of the volcano trying to destroy our sensors). I got lucky in some cases but it would have been better, probably, to stick to "core" CS projects that didn't involve straying too far from the lab. I can sure as hell figure out how to program a Linux box to do what I want -- had that volcano not been erupting, though, we wouldn't have gotten our paper published.<br />
<br />
<b>Taking on too many students.</b> This goes along with the too-many-projects problem described above. I dreamed of having a big group, and I did. I had something like a dozen PhD students, undergrads, and postdocs rotating through my group at any given time. This ends up being a vicious cycle, as the more people in the group, the more time I had to spend writing grant proposals, and had less time to mentor them and go deep on their research. I seriously had PhD students where I reckon I spent more time writing grants to cover their salary than they spent working in the lab. If I had just, say, three or four good PhD students that would have been so much easier to manage.<br />
<br />
<b>Wasted too much time courting companies for money.</b> I did not know how to play the funding game, and had unrealistic expectations of the value of visiting companies and drumming up interest in my work with them. I took countless trips to random companies up and down the Eastern seaboard, most of which did not pan out in terms of funding or collaborations. I should have stuck with the more obvious funding opportunities (NSF, Microsoft) and not blown so much energy on getting little bits of money here and there from companies that didn't understand how to fund academic research.<br />
<br />
<b>Way, way, way too much travel.</b> I had to go to every goddamn conference, workshop, program committee meeting, NSF panel, you name it. I never turned down an invitation to speak somewhere, no matter how far afield from my core community and how little influence it would have on my career. I'd travel at least twice a month, sometimes more. I'd go to a conference, come home, and turn around and see the <i>same set of people</i> just a few weeks later at some other event. There were times when I felt that my airline status was more important to maintain than my marriage.<br />
<br />
Conferences are a huge time sink. You don't go to see the talks -- if I need to read a paper and have questions about it I can email the authors. Sometimes it was just about having beers with my academic friends in an exotic location (like, say, upstate New York). Still, what an expensive and tiring way to maintain a social life. There's also way too many of them -- there should be <a href="http://matt-welsh.blogspot.com/2015/05/a-modest-proposal-sosigcommobixdi.html">just one big event a year</a> where everyone would show up.<br />
<br />
<b>All the boondoggles.</b> I wasted an incredible amount of time on little side projects that didn't need me. Each one might not be much of a time sink, but they really add up. Editorial board of a journal. PC chair of random, forgettable workshops. Serving on all manner of random committees. I found it hard to avoid this trap because you think, well, saying no means you're not going to get asked to do the more important thing next time. I have a feeling it doesn't work that way.<br />
<br />
Hard to say if I could have really done things differently, and I know lots of faculty who seem to keep their shit together despite doing everything "wrong" on the list above. So maybe it's just me.<br />
<br /></div>
Unknownnoreply@blogger.com9tag:blogger.com,1999:blog-9186457242428335144.post-3974877114615673142016-01-06T22:14:00.002-08:002016-01-06T22:24:51.771-08:00Academics, we need to talk.<div dir="ltr" style="text-align: left;" trbidi="on">
Although I made the move to industry a bit more than five years ago, I still serve on program committees and review articles for journals and the like. So it's painful for me to see some of my academic colleagues totally botch it when it comes to doing industry-relevant research. Profs, grad students: we need to talk.<br />
<br />
<span style="background-color: white; color: #333333; font-family: Georgia, Utopia, 'Palatino Linotype', Palatino, serif; font-size: 14.85px; line-height: 20.79px;">(Standard disclaimer: This is my personal blog and the opinions expressed here are mine alone, and most certainly not that of my employer.)</span><br />
<br />
Of course, many academics do a great job of visionary, out-of-the-box, push-the-envelope research that inspires and drives work in industry. I'm talking about stuff like <a href="http://abstract.cs.washington.edu/~shwetak/">Shwetak Patel's</a> increasingly insane ways of inferring activities from random signals in the environment; <a href="http://people.csail.mit.edu/dina/">Dina Katabi's</a> rethinking of wireless protocols; and pretty much anything that <a href="https://en.wikipedia.org/wiki/David_Patterson_(computer_scientist)">David Patterson</a> has ever done. Those folks (and many others) are doing fine. Keep it up.<br />
<br />
But the vast majority of papers and proposals I read are, well, crap. Mostly I'm involved in mobile, wireless, and systems, and in all three of these subfields I see plenty of academic work that tries to solve problems relevant to industry, but often gets it badly wrong. I don't quite know why this happens, but I have some ideas of how we might be able to fix it.<br />
<br />
Now, I don't think all academic research has to be relevant to industry. In some sense, the best research (albeit the riskiest and often hardest to fund) is stuff going way beyond where industry is focused today. Many academics kind of kid themselves about how forward-thinking their work is, though. Working on <a href="http://www.dna.caltech.edu/~winfree/">biomolecular computation</a>? That's far out. Working on building a faster version of MapReduce? Not so much. I'd argue most academics work on the latter kind of problem -- and that's fine! -- but don't pretend you're immune from industry relevance just because you're in a university.<br />
<br />
My first piece of advice: <b>do a sabbatical or internship in industry. </b>It's probably the best way to get exposed to the real world problems -- and the scale and complexity -- that you want to have as inspiration for your work. It drives me insane to see papers that claim that some problem is "unsolved" when most of the industry players have already solved it, but they didn't happen to write an NSDI or SIGCOMM paper about it. Learn about what's going on in the real world and what problems are both being actively worked on, and what will be important a few years down the line. If you buy me a beer I'll spend a lot of time telling you what's hard at Google and what we need help with. Hint: It ain't yet another multihop routing protocol.<br />
<br />
And by "industry", I do not mean "an academic research lab that happens to reside at a company." You can spend time there and learn a lot, but it isn't getting quite the level of product exposure I have in mind.<br />
<br />
For this to work, <b>you have to work on a real product team</b>. I know this sounds like a waste of time because you probably won't get a paper out of it, but it can be an extremely eye-opening experience. Not only do you start to understand the constraints that real products have -- like, oh, <i>it actually has to work</i> -- but you also pick up on good engineering practices: bug tracking, code reviews, documentation. You get your hands dirty. You might even launch something that other people use (I know, crazy, right?).<br />
<br />
Second: <b>don't get hung up on who invents what.</b> Coming from academia, I was trained to fiercely defend my intellectual territory, pissing all over anything that seemed remotely close to my area of interest. Industry is far more collaborative and credit is widely shared. If another team has good ideas, and can help you achieve your goals faster, join them -- and build upon that common success. So much bad academic work seems to boil down to someone trying to be so differentiated and unique that they paint themselves in a sparkly, rainbow-colored corner that, yes, ensures you stand out, but means you're often going about things the wrong way. Unfortunately, the publish-or-perish culture of academia often forces people to add arbitrary differentiation to their work so they can't be accused of being derivative. That's too bad, because a tremendous amount of value can be derived by refining and improving upon someone else's ideas.<br />
<br />
Third: <b>hold yourself to a higher standard.</b> Program committees can be brutal, but I don't think they go far enough when it comes to setting the bar for real-world relevance. Collecting data from a dozen students running your little buggy mobile app is nothing compared to industry scale. Even if you can't get a million or a hundred million people using your app, what would it take? Wouldn't it have to work on a lot of different phone platforms? Not badly impact battery life? Actually be secure? Use a server running somewhere other than under a grad student's desk? Possibly have a unit test or two in the code?<br />
<br />
Now, I know what you're thinking -- all of this is a distraction, since you don't <i>need</i> to go this extra mile to get that paper submitted. That's true. But if you're trying to do industry-relevant work, it helps to look at things through an industry lens, which means going beyond the "it ran once and I got the graphs" prototypes you're probably building. Why doesn't Google just rewrite Android in Haskell, or why doesn't Facebook just throw away their filesystem and use yours instead? Maybe it has something to do with some of these annoying "engineering problems".<br />
<br />
Finally, try to <b>keep an open mind</b> about how your research can have impact and relevance. A lot of academics get so laser-focused on impressing the next program committee that they fail to see the big picture. It's like being a chef that's only out to impress the restaurant critics and can't cook a decent goddamn hamburger. <a href="http://www.cs.berkeley.edu/~culler/">My PhD advisor</a> never seemed to care particularly about publishing papers; rather, he wanted to move the needle for the field, and he did (multiple times). Over-indexing on what's going to impress the tiny set of people reviewing SOSP or MobiCom papers is a missed opportunity. Racking up publications is fine, but if you want to have impact on the real world, there's a lot more you can do.</div>
Unknownnoreply@blogger.com42tag:blogger.com,1999:blog-9186457242428335144.post-73862273252932571132015-08-26T13:54:00.004-07:002015-08-26T13:54:59.797-07:00What I learned about mobile usage in Indonesia<div dir="ltr" style="text-align: left;" trbidi="on">
A couple of weeks ago I traveled to Jakarta to understand mobile (and especially mobile browser) usage in Indonesia. Indonesia is a huge country with a population of nearly 250 million people and a vast number of them are getting online. For many, smartphones are the first and only device they use for accessing the Internet. I wanted to share some of the things I learned interviewing a number of Indonesian smartphone users.<br />
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 14.6667px; line-height: 1.38; white-space: pre-wrap;"><br /></span></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://1.bp.blogspot.com/-wUoKw2zzfDQ/Vd4m_DQrJBI/AAAAAAABmnM/NiOwnATjfk4/s1600/IMG_20150807_190611.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="300" src="http://1.bp.blogspot.com/-wUoKw2zzfDQ/Vd4m_DQrJBI/AAAAAAABmnM/NiOwnATjfk4/s400/IMG_20150807_190611.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Phones for sale at a Lotte store in Jakarta.</td></tr>
</tbody></table>
<br />
I want to emphasize that this is my personal blog, and <b>the opinions expressed here are mine, and not that of my employer</b>.<br />
<br />
Some of my key takeaways from the week...<br />
<br />
<b>Smartphones are central to users' lives</b><br />
For everyone I interviewed, their smartphone was absolutely central to their life and was a major window to the outside world. For nearly all of these users, the smartphone is the first and only Internet-connected device they own, and they rely on their phones a great deal. Desktop or laptop Internet usage was limited to office workers or students, and even then the smartphone dominated.<br />
<br />
I saw a wide range of phones, from top-of-the-line Samsung devices all the way down to 2-3 year old, low-end Androids running badly out-of-date software. Even so, people make heavy, heavy use of their phones: for messaging, games, watching YouTube, downloading music, taking and sharing pictures ... all of the same things that "we" (meaning for the sake of this article the relatively wealthy and well-connected citizens of, say, North America or Europe) use our phones for as well.<br />
<br />
The US-centric mindset is that the phone is a "second screen" and that laptops, desktops, etc. are the main device that people use. Not so here. It's not just "mobile first", it's "mobile only".<br />
<br />
<b>Mobile data is cheap and connectivity nearly ubiquitous</b><br />
I was surprised at how inexpensive mobile data was and how well connected the city and suburbs of Jakarta were. For 100,000 rupiah -- less than $8 -- I bought 2GB of data. A huge range of data pack options were available, but the typical price seems to be around $4 per GB. Now, for many Indonesians this is not as cheap as it sounds to me, but it's still quite affordable -- less than filling up a tank of gas for your motorbike.<br />
<br />
Everyone I met used prepaid mobile data: Typically they would "top up" by buying a voucher or card at a kiosk -- with cash -- which would give them another couple of GB of data. The carrier sends an SMS when the quota is about to run out, and much like filling up on gas, you'd head to the kiosk and get another card. Various other approaches were used -- some people would SMS a person they knew, who would top up for them and then pay them by transferring money through their bank account. We didn't meet anyone who had an account with a mobile carrier and got billed regularly.<br />
<br />
Some users had an "unlimited" data plan, but when they went over a certain quota the speed would drop down to something almost unbearable -- as bad as 16 Kbps in some cases.<br />
<br />
Overall, though, network performance was quite good, and I used my phone extensively on Telkomsel's network with few problems, even out in the boonies. The folks we interviewed generally did not express problems with connectivity -- only when they would travel into more rural areas was this a problem. Check out <a href="http://opensignal.com/networks/indonesia/telkomsel-liputan">OpenSignalMap's coverage map of Telkomsel</a> for example -- it's pretty broad.<br />
<br />
Very few users used WiFi with any regularity on their phones. Sometimes they would join a WiFi hotspot at work or while out shopping, but cellular data seemed to be the typical way to connect.<br />
<br />
<b>The main use cases are messaging, social networking, and search, in that order</b><br />
Everyone I met used Blackberry Messenger and WhatsApp extensively. Many users were on Facebook as well, and other social networking and messaging apps such as Line, Path, and Twitter were often mentioned. For whatever reason, BBM (on Android) is hugely popular here although I got the sense that younger folks were gravitating towards WhatsApp. Users would have dozens or even hundreds of BBM and WhatsApp contacts, and many of them were getting frequent chat notifications from these apps during our interviews. Facebook seems to be tremendously popular as well.<br />
<br />
We often hear that "for many users in emerging markets, <a href="http://qz.com/333313/milliions-of-facebook-users-have-no-idea-theyre-using-the-internet/">Facebook is the Internet</a>". I didn't get that sense at all; people know about the Internet and the web, for sure, and Facebook is just another app for them (although an important one).<br />
<br />
After messaging and social networking, searching for content on the Web is pretty important. Google is widely used and highly regarded -- everyone calls it <a href="http://m-seo.heck.in/kenapa-google-sering-disebut-mbah-google.xhtml">"Mbah Google"</a> meaning the wise old grandfather who knows all. Browsers were mostly used for web searches and not much else -- indeed, none of the folks I interviewed had much if any knowledge about things like bookmarks, tabs, Incognito mode, or anything else in the browser.<br />
<br />
<b>"Death of the Web" is greatly exaggerated</b><br />
There is often a lot of hand-wringing about <a href="http://www.wsj.com/articles/the-web-is-dying-apps-are-killing-it-1416169934">native apps spelling the "death" of the web</a>. Apps are popular, sure, but they don't seem to replace any of the use cases for the Web on mobile, at least for these users. I wouldn't expect -- or even want -- mobile websites to replace WhatsApp or Facebook. That seems like a losing proposition to me, and I don't fully understand the drive to make mobile websites more "like apps". Despite the popularity of apps, the Web, and Web search, still play a huge role on mobile devices for these users -- I don't see that going away any time soon.<br />
<br />
<b>Nobody can update anything, because their storage is full</b><br />
Nearly everyone I met had maxed out the storage on their phones -- typically 8GB or more -- presumably downloading pictures, videos, games, and so forth. (It seems that WhatsApp automatically stores all images downloaded from a conversation into the local device, which might be a major contributor, given its popularity here.) As a result, nobody was able to update their apps, even when Chrome (for example) reminds them to do so. We saw a lot of out-of-date app versions being used, and people told us they have been unable to update due to storage constraints. (I was expecting people to tell me they didn't update apps because of data quota limits, but that didn't seem to be a major issue.) I don't know what can be done about this -- some way to automatically zap old WhatsApp images or something -- but it obviously creates problems for users when they are using buggy or insecure versions of things.<br />
<br />
<b>The future looks bright</b><br />
Despite all of the challenges I saw, I came away with an extremely optimistic outlook for mobile users in Indonesia. I was impressed with how pervasive smartphones and mobile network connectivity were. I was glad to see that data cost was not a huge barrier to use -- apart from YouTube, people seemed able to purchase enough mobile data for their typical needs. Devices and connectivity are only going to get better and more affordable. It's a really exciting time to be working in this space.</div>
Unknownnoreply@blogger.com13tag:blogger.com,1999:blog-9186457242428335144.post-18094089767357961702015-05-05T11:28:00.002-07:002015-05-05T11:28:25.049-07:00A modest proposal: SOSIGCOMMOBIXDI<div dir="ltr" style="text-align: left;" trbidi="on">
I have a problem: there are way too many conferences to attend. Even worse, the degree of overlap between the systems, mobile, and networking communities means that I am basically running into the same people at all of these events. You have a problem, too: You are paying money (and time) to attend all of these separate conferences.<br />
<br />
Conservatively, there are five "top tier" conferences that are "must attend" events every year: SOSP/OSDI, NSDI, MobiSys, MobiCom, SIGCOMM. (Not to mention excellent venues like USENIX ATC, EuroSys, CoNext, SenSys, the list goes on.) And then all of the "smaller workshops because we don't like how big the conferences are but you pretty much have to go anyway": HotOS, HotMobile, HotNets.<br />
<br />
Realistically, nobody makes it to all of these events (unless you're, say, a poor junior faculty member going for tenure and have to show your place in as many places as possible). So you pick and choose based on whether you have a paper accepted, or whether you have enough travel money laying around, or whether you just have to get away from home for a few days.<br />
<br />
Consider the costs of running all of these separate events. For the attendees, there is the high cost (and time investment) for travel, registration fees, and taking time away from work and home to attend each conference. A single conference trip probably costs $1500-2000, more if you are traveling overseas, and anywhere from three days to a week of time away from home. Especially for those with young children at home each trip takes a serious toll.<br />
<br />
Organizing a conference is also a huge amount of work, regardless of whether it's a workshop for 50 people or a big conference for 500. This is especially true for the <a href="http://matt-welsh.blogspot.com/2015/02/how-do-you-become-conference-chair.html">poor general chair</a> who has to work out all of the details of the venue, hotel, meals, A/V setup, finances, etc.<br />
<br />
You know where this is going: <b>Why don't we have one, big, annual conference spanning the systems, networking, and mobile research communities?</b> (And, while we're at it, why not throw in databases for good measure?) SOSIGCOMMOBIXDI would run for, say, 5 days, with parallel (yes!) sessions covering each of these major areas. It would happen at roughly the same week each year, so people can plan their travel and vacation schedules well in advance. It's like <a href="http://fcrc.acm.org/">FCRC</a>, for systems!<br />
<br />
I can hear the objections now! Let me take them one by one.<br />
<br />
<b>But won't it be too big?</b> SIGCOMM and SOSP/OSDI already have something like 600 people in attendance; these are hardly close-knit communities. Given the amount of overlap across these various conferences, I estimate that there would be no more than 3,000 people attending SOSIGCOMMOBIXDI, although I'll grant I might be underestimating -- let's be generous and say 5,000 people. Organizing an event for 5,000 people is no big deal. Most large cities have hotels and convention centers that can comfortably handle events of this size. Hell, medical conferences typically have 10,000 or more (<a href="http://c.ymcdn.com/sites/www.hcea.org/resource/resmgr/docs/june_2014_top_50_total_atten.pdf">way more</a>) attendees. It is understood how to run conferences at this scale. It's not something a typical professor has experience doing, so best to rely on a professional events organization like USENIX.<br />
<br />
I have been to <a href="http://velocityconf.com/velocity2014">5,000-person conferences</a> and if anything, it's more energizing -- and there is much more to do -- than these 500-person events where everyone is expected to sit in the same room listening to the same talks all day long. You have room for smaller breakouts and workshops; a larger, more interesting industry presence; and greater draw for really interesting keynote speakers.<br />
<br />
<b>But I want a single track!</b> Get over it. The single-track "constraint" is often cited by senior people who remember what it was like in the early days of the field when conferences were 1/5th the size that they are now, and every PC member read every paper. The people who complain about parallel tracks are often the ones who spend most of the conference out in the hall chatting with their colleagues -- they're not listening to every talk anyway. Even if they sit in the room all day they're probably on their laptops pretending to listen to the talk, or writing blog posts (like I'm doing now).<br />
<br />
Ever been to the morning session on the third day of a conference? Crickets. Where are all of the "single-trackers" then?<br />
<br />
Moreover, the single-track "constraint" severely limits the number of papers a conference can publish every year. Most 2.5-day conference can take no more than 25-30 papers to fit in a single track model. To squeeze more papers in, we've gotten rid of the more memorable aspects of these conferences: keynotes, panels, breakouts. It doesn't scale.<br />
<br />
Removing the single-track requirement also opens up a bunch of possibilities for changing up the format of the conference. Sure, you want some large plenary sessions and a few tracks of papers. But hosting a few mini-workshops, working sessions, or BoFs during the day is possible too. Squeeze in poster and demo sessions here and there. Even set some space aside for an industry trade show (these are often really fun, but most academic conferences rarely have them).<br />
<br />
Worried you're going to miss something? The papers are all online, and USENIX even posts videos of all of the talks. So, I claim that the single-track model is outdated.<br />
<br />
<b>But then there's only one paper submission deadline a year!</b> Not necessarily. We could have rolling submissions for SOSIGCOMMOBIXDI, much like <a href="http://www.sigmod2015.org/calls_papers_sigmod_research.shtml">SIGMOD</a> and some other venues do. Since SOSIGCOMMOBIXDI practically consists of multiple federated events, each one can have its own set of deadlines, and they could be staggered across sub-events. Paper submission and evaluation are only loosely coupled to the timing of the conference itself.<br />
<br />
<b>But ACM and USENIX won't get as much conference registration revenue if there's only one event!</b> Oh, I hadn't thought of that.<br />
<br /></div>
Unknownnoreply@blogger.com6tag:blogger.com,1999:blog-9186457242428335144.post-6956888375982622592015-04-30T22:22:00.003-07:002015-04-30T22:22:34.626-07:00Flywheel: Google's Data Compression Proxy for the Mobile Web<div dir="ltr" style="text-align: left;" trbidi="on">
Next week, we'll be presenting our work on the <a href="https://support.google.com/chrome/answer/2392284?hl=en">Chrome Data Compression proxy</a>, codenamed Flywheel, at <a href="https://www.usenix.org/conference/nsdi15">NSDI 2015</a>. Here's a link to the <a href="https://drive.google.com/open?id=0B9coPBZbv_ugaXdycy1YcGp2WlU&authuser=1">full paper</a>. Our wonderful intern and Berkeley PhD student <a href="http://www.eecs.berkeley.edu/~rcs/">Colin Scott </a>will be giving the talk. (I'm happy to answer questions about the paper in the comments section below.)<br />
<br />
It's safe to say that the paper would have never happened without Colin -- most of us are too busy building and running the service to spend the time it takes to write a really good paper. Colin's intern project was specifically to collect data and write a paper about the system (he also contributed some features and did some great experiments). It was a win-win situation since we got to offload most of the paper writing to Colin, and he managed to get a publication out of it!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-aSzuqHkvZFM/VUMI6mme2KI/AAAAAAABlT4/wpkmKcHuulY/s1600/datasavingsduo_v3.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-aSzuqHkvZFM/VUMI6mme2KI/AAAAAAABlT4/wpkmKcHuulY/s1600/datasavingsduo_v3.png" height="358" width="400" /></a></div>
<br />
Rather than summarize the paper, I thought I'd provide some backstory on Flywheel and how it came about. It's a useful story to understand how a product like this goes from conception to launch at a company like Google.<br />
<br />
(That said, standard disclaimer applies: This is my personal blog, and the opinions expressed here are mine alone.)<br />
<br />
<b>Backstory: Making the mobile web fast</b><br />
<br />
When I moved to Seattle in 2011, I was given the mission to start a team with a focus on <a href="http://matt-welsh.blogspot.com/2011/05/what-im-working-on-at-google-making.html">improving mobile Web performance</a>. I started out by hiring folks like <a href="https://www.linkedin.com/pub/ben-greenstein/5/34/507">Ben Greenstein</a> and <a href="http://www.michaelpiatek.com/">Michael Piatek</a> to help figure out what we should do. We spent the first few months taking a very academic approach to the problem: Since we didn't understand mobile Web performance, of course we needed to measure it!<br />
<br />
We built a measurement tool, called Velodrome, which allowed us to automate the process of collecting Web performance data on a fleet of phones and tablets -- launching the browser with a given URL, measuring a bunch of things, taking screenshots, and uploading the data to an AppEngine-based service that monitored the fleet and provided a simple REST API for clients to use. We built a ton of infrastructure for Velodrome and used it on countless experiments. Other teams at Google also started using Velodrome to run their own measurements and pretty soon we had a few tables full of phones and tablets churning away 24/7. (This turned out to be a lot harder than we expected -- just keeping them running continuously without having to manually reboot them every few hours was a big pain.)<br />
<br />
At the same time we started working with the <a href="https://developers.google.com/speed/pagespeed/">PageSpeed</a> team, which had built the gold standard proxy for optimizing Web performance. PageSpeed was focused completely on desktop performance at the time, and we wanted to develop some mobile-specific optimizations and incorporate them. We did a bunch of prototyping work and explorations of various things that would help.<br />
<br />
The downside to PageSpeed is that sites have to install it -- or opt into Google's <a href="https://developers.google.com/speed/pagespeed/service">PageSpeed Service</a>. We wanted to do something that would reach more users, so we started exploring building a browser-based proxy that users, rather than sites, could turn on to get faster Web page load times. (Not long after this, Amazon announced their <a href="http://docs.aws.amazon.com/silk/latest/developerguide/introduction.html">Silk</a> browser for the Kindle Fire, which was very much the same idea. Scooped!)<br />
<br />
<b>Starting a new project</b><br />
<b><br /></b>
Hence we started the Flywheel project. Initially our goal was to combine PageSpeed's optimizations, the new <a href="https://www.chromium.org/spdy/spdy-whitepaper">SPDY protocol</a>, and some clever server-side pre-rendering and prefetching to make Web pages load lightning fast, even on cellular connections. The first version of Flywheel, which we built over about a year and a half, was built on top of PageSpeed Service.<br />
<br />
Early in the project, we learned of the (confidential at the time) effort to port Chrome to Android and iOS. The Chrome team was excited about the potential for Flywheel, and asked us to join their team to launch it as a feature in the new browser. The timing was perfect. However, the Chrome leadership was far more interested in a proxy that could <i>compress</i> Web pages, which is especially important for users in emerging markets, on expensive mobile data plans. Indeed, many of the original predictive optimizations we were using in Flywheel would have resulted in substantially greater data usage for the user (e.g., prefetching the next few pages you were expected to visit). It also turned out that compression is way easier than performance, so we decided to focus our efforts on squeezing out as many bytes as possible. (A common mantra at the time was "no bytes left behind".)<br />
<br />
<b>Rewriting in Go</b><br />
<br />
As we got closer to launching, we were really starting to feel the pain of bolting Flywheel onto PageSpeed Service. Originally, we planned to leverage many of the complex optimizations used by PageSpeed, but as we focused more on compression, we found that PageSpeed was not well-suited to our needs, for a bunch of reasons. In early 2013, Michael Piatek convinced me that it was worth trying to rewrite the service, from scratch, in <a href="https://golang.org/">Go</a> -- as a way of both doing a clean redesign from scratch but also leveraging Go's support for building Google-scale services. It was a big risk, but we agreed that if the rewrite wasn't bearing fruit in just a couple of months that we'd stop work on it and go back to PageSpeed.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-EXuWuDisIdQ/VUMJX-4czDI/AAAAAAABlUA/i6JjMh9uDbw/s1600/gopher.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-EXuWuDisIdQ/VUMJX-4czDI/AAAAAAABlUA/i6JjMh9uDbw/s1600/gopher.png" /></a></div>
<br />
Fortunately, Michael and the rest of the team executed at lightning speed and in just a few months we had substantially reimplemented Flywheel in Go, a <a href="http://matt-welsh.blogspot.com/2013/08/rewriting-large-production-system-in-go.html">story documented elsewhere on this blog</a>. In November 2013 I submitted a CL to delete the thousands of lines of the PageSpeed-based Flywheel implementation, and we switched over entirely to the new, Go-based system in production.<br />
<br />
PageSpeed Service in C++ was pushing 270 Kloc at the time. The Go-based rewrite was just 25 Kloc, 13Kloc of which were tests. The new system was much easier to maintain, faster to develop, and gave our team sole ownership of the codebase, rather than having to negotiate changes across the multiple teams sharing the PageSpeed code. The bet paid off. The team was much happier and more productive on the new codebase, and we managed to migrate seamlessly to the Go-based system well before the full public launch.<br />
<br />
<b>Launching</b><br />
<br />
We announced support for Flywheel in the M28 beta release of Chrome at Google I/O in 2013, and finally launched the service to 100% of Chrome Mobile users in January 2014. Since then we've seen tremendous growth of the service. More than 10% of all Chrome Mobile users have Flywheel enabled, with percentages running much higher in countries (like Brazil and India) where mobile data costs are high. The service handles billions of requests a day from millions of users. Chrome adoption on mobile has skyrocketed over the last year, and is now the #1 mobile browser in many parts of the world. We also <a href="https://chrome.google.com/webstore/detail/data-saver-beta/pfmgfdlgomnbgkofeojodiodmgpgmkac?hl=en">recently launched Flywheel for Chrome desktop and ChromeOS</a>. Every day I check the dashboards and see traffic going up and to the right -- it's exciting.<br />
<br />
We came up with the idea for Flywheel in late 2011, and launched in early 2014 -- about 2.5 years of development work from concept to launch. I have no idea if that's typical at Google or anywhere else. To be sure, we faced a couple of setbacks which delayed launch by six months or more -- mostly factors out of our control. We decided to hold off on the full public release until the Go rewrite was done, but there were other factors as well. Looking back, I'm not sure there's much we could have done to accelerate the development and launch process, although I'm sure it would have gone faster had we been doing it as a startup, rather than at Google. (By the same token, launching as part of Chrome is a huge opportunity that we would not have had anywhere else.)<br />
<br />
<b>What's next?</b><br />
<b><br /></b>
Now that Flywheel is maturing, we have a bunch of new projects getting started. We still invest a lot of energy into optimizing and maintaining the Flywheel service. Much of the work focuses on making the service more robust to all of the weird problems we face proxying the whole Web -- random website outages causing backlogs of requests at the proxy, all manner of non-standards-compliant sites and middleboxes, etc. (Buy me a beer and I'll tell you some stories...) We are branching out beyond Flywheel to build some exciting new features in Chrome and Android to improve the mobile experience, especially for users in emerging markets. It'll be a while until I can write a blog post about these projects of course :-)<br />
<br />
<br /></div>
Unknownnoreply@blogger.com2tag:blogger.com,1999:blog-9186457242428335144.post-44862728580694213112015-02-12T13:33:00.001-08:002015-02-12T13:33:06.470-08:00How do you become a conference chair?<div dir="ltr" style="text-align: left;" trbidi="on">
I've served as program chair and general chair for a <a href="http://www.mdw.la/">number of conferences</a>, but the conditions under which I got asked to serve in these roles were generally a mystery to me. Now that I've served on the steering committee for several conferences, I've seen how the sausage is made and what factors contribute to an individual being asked to be the PC or general chair.<br />
<br />
If you're a junior faculty member or a relatively new industry researcher, you might be wondering how you get yourself in the right position to be tapped for these roles. A few words of advice that might be helpful.<br />
<br />
<b>Should you chair a conference?</b><br />
<b><br /></b>
Being a program or general chair requires a tremendous amount of time and energy. You should only accept such a job if you can really do a good job of it. In the past I have declined invitations for events that I didn't feel that I could really devote the appropriate amount of energy to. It was easy to turn down by saying "I don't feel that I have the cycles to do an incredible job". Doing a poor job of chairing will potentially tarnish your reputation and make it difficult for you to get such gigs in the future.<br />
<br />
In general I would recommend that you only chair <b>well-known</b> and <b>high-profile</b> conferences and workshops. Way too many people seem to think that the way to make their mark on the research world is by starting up a new conference or workshop in some area, and finding some sucker to serve as the chair. As a result we have a proliferation of third-tier workshops on various topics which don't generally attract good paper submissions, good PC members, or good attendees. These are usually a waste of time.<br />
<br />
Of course as a junior faculty member you don't get asked to chair, say, SOSP in your first or second year on the job. You have to start somewhere. Chairing a few smaller or lower-quality events is fine and gives you experience, but be extremely judicious in selecting which venues to chair. I made the mistake once or twice of agreeing to chair for a brand-new workshop which did not clearly have the buy-in from the rest of the community that it needed to exist. As a result I had a hard time getting good people to agree to be on the PC, and the submissions we got were pretty crappy. I should have said no to this (although serving as chair sounded like a great thing for my career at the time).<br />
<br />
<b>Is being general chair worth it?</b><br />
<b><br /></b>
For junior faculty, generally not. The program chai is the job you want. The general chair's job is to do all of the scut work of organizing the conference -- finding the hotel, dealing with finances, deciding on the banquet menu, begging companies for money. This work really sucks and delivers little intellectual satisfaction (unless you really like negotiating hotel contracts). The only reason to do this job is if the venue is <b>really</b> well known and you will have a chance to be fairly high profile in terms of structuring the whole event and making your mark on it. I usually think it's better for senior, more well-established people to be general chairs since they don't need to do it for career-advancement reasons.<br />
<br />
I agreed to be general chair for <a href="http://www.hotmobile.org/2014/">HotMobile last year</a>. I knew this wouldn't advance my career in any meaningful way, certainly not at Google. I did it because I like HotMobile a lot and wanted to help the community. As a junior faculty member devoting this much time to something like this would have been a mistake.<br />
<br />
<b>How do you get tapped?</b><br />
<b><br /></b>
Most conferences have a steering committee that makes the decision about who will be the program and general chair for the following year's conference. Sometimes the steering committee has standing members and sometimes it rotates (and sometimes a combination of the two).<br />
<br />
Getting chosen for a chairship comes down to a bunch of factors.<br />
<br />
<b>Overall visibility: </b>You need to be known in the community. This means showing up for the conferences, getting to know people, serving on program committees, and generally being there. If you don't ever come to a conference the chances you'll be asked to serve as its chair are vanishingly low. Note that publishing papers in these conferences is helpful but not strictly a requirement (I don't publish much anymore and keep getting asked to do things...) Being seen is more important than being published in this regard.<br />
<br />
<b>Being responsible:</b> Generally you establish your reputation as a community member by serving on program committees and doing other volunteer activities like running poster/demo sessions and the like. If you serve in these roles, it's important to be incredibly responsible: Don't miss paper review deadlines, keep people in the loop, deliver on what you promised. I've known faculty who are perennially tardy with paper reviews, don't show up in person to the PC meeting, and so forth. These people are less likely to be asked to be a chair.<br />
<br />
<b>Career stage:</b> Many conferences confer chairships on up-and-coming faculty who are at a certain stage in their career (e.g., about to come up to tenure) who are less likely to say no (and also more likely to do an excellent job).<br />
<br />
<b>Knowing the right people:</b> This is part of overall visibility, but if you don't have any kind of personal relationship with the folks who will eventually be making these decisions, it's less likely they'll think of you when the time comes. Going to conferences, going out for dinner and drinks after the conference, and generally being chummy with other senior folks in the field is pretty important. I know plenty of people who do second-rate research but are seen as members of the inner cabal mainly because they always show up to the conference and are up for getting beers. (Indeed this may well explain most of my own career path!)<br />
<br />
<br />
<br />
<br />
<br />
<br /></div>
Unknownnoreply@blogger.com4tag:blogger.com,1999:blog-9186457242428335144.post-31231797995890506992015-01-22T21:00:00.000-08:002015-01-22T21:00:25.219-08:00Day in the Life of a Google Manager<div dir="ltr" style="text-align: left;" trbidi="on">
Not long after joining Google back in 2010, <a href="http://matt-welsh.blogspot.com/2010/12/day-in-life-of-googler.html">I wrote this cheeky piece</a> contrasting my daily schedule at Google with my previous career as an academic. Looking back on that, it's remarkable how much my schedule has changed in four years, in no small part because I'm now managing a team and as a result end up doing a lot less coding than I used to.<br /><div>
<br /></div>
<div>
So, now seems like a good time to update that post. It will also help to shed some light on the differences between a pure "individual contributor" role and the more management-focused role that I have now.</div>
<div>
<br /></div>
<div>
By way of context: My role at Google is what we call a "tech lead manager" (or TLM) which means I'm responsible both for the technical leadership of my team as well as the people-management side of things. <a href="http://matt-welsh.blogspot.com/2013/04/running-software-team-at-google.html">I've posted more details about the TLM role elsewhere</a>, so I won't repeat that here. Our team has various projects, the largest and most important of which is the <a href="https://developer.chrome.com/multidevice/data-compression">Chrome data compression proxy</a> service. We're generally interested in making Chrome work better on mobile devices, especially for users in slow, expensive networks in emerging markets.</div>
<div>
<br /></div>
<div>
The best part of my job is how varied it is and every day is different (and I usually have a lot of balls in the air). The below is meant to represent a "typical" day although take that with a grain of salt given the substantial inter-day variation:</div>
<blockquote style="text-align: left;">
6:45am - Wake up, get the kids up and get them ready and make them breakfast, shower. </blockquote>
<blockquote style="text-align: left;">
8:30am - Jump on my bike and ride to work (which takes about 10 minutes), grab breakfast and head to my desk. </blockquote>
<blockquote style="text-align: left;">
8:45am - Check half a dozen dashboards showing various metrics for how our services are doing -- traffic is up, latency and compression are stable, datacenters are happily churning along. </blockquote>
<blockquote style="text-align: left;">
9:00am - Catch up on email. This is a continuous struggle and a constant drain on my attention, but lately I've been using <a href="http://www.google.com/inbox/">Inbox</a> which has helped me to stay afloat. Barely. </blockquote>
<blockquote style="text-align: left;">
9:30am - Work on a slide deck describing a new feature we're developing for Chrome, incorporating comments from one of the PMs. The plan is to share the deck with some other PM and eng leads to get buy-in and then start building the feature later this quarter. </blockquote>
<blockquote style="text-align: left;">
10:00am - Chat with one of my teammates about a bug report we're chasing down, which gets me thinking about a possible root cause. Spend the next half hour running queries against our logs to confirm my suspicions. Update the bug report with the findings. </blockquote>
<blockquote style="text-align: left;">
10:30am - I somehow find my morning has not been fully booked with meetings so I have a luxurious hour to do some coding. Try to make some headway on rewriting one of our MapReduce pipelines in Go, with the goal of making it easier to maintain as well as adding some new features. It's close to getting done but by the time my hour is up one of the tests is still failing, so I will spend the rest of the day quietly fuming over it. </blockquote>
<blockquote style="text-align: left;">
11:30am - Meet with one of my colleagues in Mountain View by video hangout about a new project we are starting up. I am super excited to get this project going. </blockquote>
<blockquote style="text-align: left;">
12:00pm - Swing by the cafe to grab lunch. I am terrible about eating lunch at my desk while reading sites like Hacker News - some habits die hard. Despite this, I still do not have the faintest clue how Bitcoin works.</blockquote>
<blockquote style="text-align: left;">
12:30pm - Quick sync with a team by VC about an internal summit we're organizing, to plan out the agenda. </blockquote>
<blockquote style="text-align: left;">
1:00pm - Hiring committee meeting. We review packets for candidates that have completed their interview loops and try to decide whether they should get a job offer. This is sometimes easy, but often very difficult and contentious, especially with candidates who have mixed results on the interview loop (which is almost everyone). I leave the meeting bewildered how I ever got a job here.</blockquote>
<blockquote style="text-align: left;">
2:00pm - Weekly team meeting. This usually takes the form of one or more people presenting to the rest of the team something they have been working on with the goal of getting feedback or just sharing results. At other times we also use the meeting to set our quarterly goals and track how we're doing. Or, we skip it.</blockquote>
<blockquote style="text-align: left;">
3:00pm - One-on-one meeting with a couple of my direct reports. I use these meetings to check in on how each member of the team is doing, make sure I understand their latest status, discuss any technical issues with their work, and also talk about things like career development, setting priorities, and performance reviews. </blockquote>
<blockquote style="text-align: left;">
4:00pm - Three days a week I leave work early to get in an hour-long bike ride. I usually find that I'm pretty fried by 4pm anyway, and this is a great way to get out and enjoy the beautiful views in Seattle while working up a sweat. </blockquote>
<blockquote style="text-align: left;">
5:00pm - Get home, shower, cook dinner for my family, do some kind of weird coloring or electronics project with my five-year-old. This is my favorite time of day. </blockquote>
<blockquote style="text-align: left;">
7:00pm - Get the kids ready for bed and read lots of stories. </blockquote>
<blockquote style="text-align: left;">
8:00pm - Freedom! I usually spend some time in the evenings catching up on email (especially after having skipped out of work early), but try to avoid doing "real work" at home. Afterwards, depending on my mood, might watch an episode of Top Chef with my wife or read for a while (I am currently working on Murakami's <i>1Q84</i>).</blockquote>
<div style="text-align: left;">
Compared to my earlier days at Google, I clearly have a <i>lot</i> more meetings now, but I'm also involved in many more projects. Most of the interesting technical work is done by the engineers on my team, and I envy them -- they get to go deep and do some really cool stuff. At the same time I enjoy having my fingers in lots of pies and being able to coordinate across multiple active projects, and chart out new ones. So it's a tradeoff.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
Despite the increased responsibilities, my work-life balance still feels much better than as an academic. Apart from time-shifting some of my email handling to the evening (in order to get the bike rides in), I almost never deal with work-related things after hours or on the weekends. I have a lot more time to spend with my family and generally manage to avoid having work creep into family time. The exception is when I'm on pager duty, which is another story entirely -- getting woken up at 3 am to deal with a crash bug in our service is always, um, exciting.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
<br /></div>
</div>
Unknownnoreply@blogger.com18tag:blogger.com,1999:blog-9186457242428335144.post-30073035233946468312014-10-15T14:33:00.001-07:002014-10-15T14:33:25.365-07:00You'll be fine in Silicon Valley<div dir="ltr" style="text-align: left;" trbidi="on">
Yesterday, a group of well-known professors from a bunch of universities <a href="http://thmatters.wordpress.com/2014/10/14/letter-re-closing-of-microsoft-research-silicon-valley/">sent an open letter to Microsoft Research's leadership</a>, condemning them for closing the Microsoft Research Silicon Valley lab and leaving the researchers there "jobless". Although I know and respect many of the authors of this letter, I think they get it wrong when it comes to the career opportunities for the Microsoft researchers impacted by the lab's closing, and more broadly for the impact this closing will have on the research community.<br />
<br />
The letter's tone is incredibly haughty -- a mixture of "how dare you" and "think of the children!!" What worries me the most is the message the letter seems to be sending to junior researchers who may feel that industry jobs are not a viable career path, because, hey, you might get fired if your lab closes. I think we should correct some of these misconceptions.<br />
<br />
(Standard disclaimer: This is my personal blog and the opinions expressed here are mine alone, and most certainly not that of my employer.)<br />
<br />
Let's take the letter point by point.<br />
<br />
<blockquote class="tr_bq" style="background-color: white; color: #555555; font-family: 'Droid Serif', arial, serif; font-size: 14px; line-height: 22px; padding: 0px 0px 20px;">
By now, you are no doubt aware of the research community’s shock and disappointment at the sudden and harsh way in which the members of the Microsoft Research Silicon Valley lab were dismissed a few weeks ago. </blockquote>
While the news was sudden, I don't have any evidence that it was "harsh". That's how layoffs sometimes work. Yes, it sucks, but don't imply malice where none is intended.<br />
<br />
<blockquote class="tr_bq" style="background-color: white; color: #555555; font-family: 'Droid Serif', arial, serif; font-size: 14px; line-height: 22px; padding: 0px 0px 20px;">
We are writing to share our perspective on the negative impacts of the shutdown and to open a dialogue about the ways in which Microsoft can try to restore the environment that enabled MSR to produce such great research in the past, benefiting both the company and the world.</blockquote>
The implication here is that by closing the Silicon Valley lab, Microsoft has damaged "the environment" that enabled them to "produce such great research". Let's see here. By my count, about 75 researchers out of a worldwide organization of <a href="http://research.microsoft.com/en-us/about/default.aspx">"more than 1,000 scientists and engineers"</a> were affected. While this is unfortunate, I don't think it's going to seriously hinder Microsoft's ability to do great work in the future. It's still a great place and I expect it will continue to grow.<br />
<br />
<blockquote class="tr_bq" style="background-color: white; color: #555555; font-family: 'Droid Serif', arial, serif; font-size: 14px; line-height: 22px; padding: 0px 0px 20px;">
While layoffs are always unpleasant, the impact of this one has been exacerbated by the fact that many researchers at the Silicon Valley lab worked on long-term, fundamental research of the kind that can be done at very few places outside of academia. </blockquote>
The fact that "very few places outside of academia" allow one to do "long-term, fundamental research" should be teaching us something. The authors of this letter seem to believe that doing academic-style research is some kind of special, protected occupation that people with PhDs are entitled to. While there may have been plenty of industry labs doing pure, academic-style research 20 or 30 years ago, the world has changed. What worries me is that professors still cling to an industry research model that has largely been supplanted by other, better models. I think it's time to evolve our thinking about this in the community and start giving appropriate career advice to students so they are prepared for the reality of what's out there, rather than for an outmoded academic ideal.<br />
<br />
It is also a common misconception that one cannot do research in a more product-oriented industry setting. For example, Google does a tremendous amount of research, albeit <a href="http://cacm.acm.org/magazines/2012/7/151226-googles-hybrid-approach-to-research/fulltext">using a fairly different model</a> than places like MSR. The same is true for other large and small companies as well. We may not call all of these places "research labs" and bestow fancy titles on people like "research scientist", but the research is still happening, and having tremendous impact.<br />
<br />
<blockquote class="tr_bq" style="background-color: white; color: #555555; font-family: 'Droid Serif', arial, serif; font-size: 14px; line-height: 22px; padding: 0px 0px 20px;">
As you know, the academic calendar is such that many of these researchers, including very junior ones who recently completed their PhDs, could be jobless for nearly an entire year. We feel that there should have been a better way to close down this lab, one that would have allowed them to have continuous employment until academic jobs are available again in September 2015. Given that this lab was continuing to produce exceptional — indeed revolutionary — research, we fail to understand why closing it had to be done so suddenly.</blockquote>
This is completely disconnected from reality. First of all, where did anyone get the idea that the only viable job opportunities for the researchers being let go from MSR SV are in academia? From what I can tell, all of these people are being heavily recruited by a number of Bay Area companies. Hell, the MSR SV office is literally <i>off of the same highway exit</i> as the Google headquarters. About the only thing that might change for some of these people is which parking lot they drive to in the morning.<br />
<br />
I very seriously doubt that any of these researchers will be "jobless" for any length of time. That's delusional.<br />
<br />
Second, as a friend of mine pointed out, it's not as though the "academic calendar" is some kind of law of physics. If universities are serious about recruiting some of these people, I am sure they can find a way to make it happen, even if they have to resort to such lengths as hiring them on short-term contracts as visiting scientists or whatever. The academic calendar is your problem, not Microsoft's.<br />
<br />
<blockquote class="tr_bq" style="background-color: white; color: #555555; font-family: 'Droid Serif', arial, serif; font-size: 14px; line-height: 22px; padding: 0px 0px 20px;">
Over the past two decades, MSR, and indeed all of Microsoft, earned an excellent reputation in academia as an organization that not only valued basic research but also supported the career development of the many researchers that worked in or visited the labs. That reputation has been significantly damaged, threatening Microsoft’s ability to recruit and retain world-class researchers. </blockquote>
It's true that shuttering MSR SV will have some impact on how people view Microsoft Research as a career choice. On the other hand, it's not as though they hired a huge number of people every year -- the total number of jobs impacted is relatively small. In comparison, Google hires <i>multiple MSR SVs</i> worth of people every week, and more PhDs per year than all of MSR employs, worldwide. (For that matter, Microsoft, as a whole, no doubt beats Google's numbers.) It's not like the loss of a small fraction of MSR's total headcount has anything but a minor impact on the overall pipeline for computer scientists.<br />
<br />
What's really happening here is a bunch of finger-wagging in an effort to publicly shame Microsoft for what was no doubt a very difficult and complex business decision.<br />
<br />
<blockquote class="tr_bq" style="background-color: white; color: #555555; font-family: 'Droid Serif', arial, serif; font-size: 14px; line-height: 22px; padding: 0px 0px 20px;">
As faculty members, we can no longer recommend it as highly to our students as a place to start their careers. In the long term, this move seems likely to adversely affect Microsoft Research (and the positive contributions it makes to Microsoft as a whole) in more ways than any benefit it may have had.</blockquote>
I think Microsoft should appoint a panel of academics to run the company, since clearly they know more about running a business than MSR leadership does.<br />
<br />
<blockquote class="tr_bq" style="background-color: white; color: #555555; font-family: 'Droid Serif', arial, serif; font-size: 14px; line-height: 22px; padding: 0px 0px 20px;">
Nevertheless, we believe that Microsoft can reduce the damage that has been caused by the shutdown of the Silicon Valley lab. We understand that Microsoft is considering ways to help care for the researchers who were dismissed, such as defraying the additional costs of the academic organizations who are trying to provide these researchers with temporary homes. This would be an excellent, and highly appreciated, first step.</blockquote>
Of course universities <i>must</i> bear the cost of supporting these poor refugees while they find new jobs! I mean, it's not like the Microsoft stock and severance package will pay the bills for very long until the affected people get jobs at Yahoo or Twitter. Hopefully the universities can pull through with basic rations, perhaps a tattered wool blanket and a cot to sleep on, an office with an aging workstation running XENIX, just until these people can find gainful employment. It would be a real humanitarian disaster otherwise.<br />
<br />
<blockquote class="tr_bq" style="background-color: white; color: #555555; font-family: 'Droid Serif', arial, serif; font-size: 14px; line-height: 22px; padding: 0px 0px 20px;">
Looking forward, we hope that you will open a discussion with us and the community about Microsoft’s vision for industrial research (which has become less clear after the closing of what appeared to be an extremely valuable and successful lab) and concrete commitments MSR can make regarding the career development of its remaining and future researchers. </blockquote>
Frankly, I don't think that the MSR leadership owes the academic community any kind of explanation or commitments whatsoever. If anything, this was a great wake-up call to anyone who was living under the false impression that being a "researcher" at a company gave you job security. This is how companies sometimes work.<br />
<br />
Fortunately, especially in Silicon Valley, there are literally hundreds of great companies that the MSR SV folks can work for, doing all kinds of awesome and groundbreaking work. The tech industry as a whole is going strong, and I have no doubt that there will be all kinds of career opportunities for these folks.<br /><br />
<blockquote class="tr_bq" style="background-color: white; color: #555555; font-family: 'Droid Serif', arial, serif; font-size: 14px; line-height: 22px; padding: 0px 0px 20px;">
Steps like these are essential to rebuilding the relationship between Microsoft and the academic community, along with all the mutual benefits that it brings.</blockquote>
On the whole, my guess is that the relationship between Microsoft and the academic community will continue to thrive. There are a lot of great people still at MSR and the ties there are incredibly strong. It's too bad that they had to shut down the Silicon Valley lab in the way that they did, but I'm not sure it's productive to cast a dark cloud over everything MSR does and stands for as a result.<br />
<br />
Mostly, I'd like the authors of this letter to think about the message they are sending to students and junior researchers, which seems off base to me. We're all sad about the loss of MSR SV, but I think this letter really goes too far when it claims that anybody there will be "jobless" or that academic positions must open up to absorb the affected researchers.</div>
Unknownnoreply@blogger.com70tag:blogger.com,1999:blog-9186457242428335144.post-59887743205359185182014-08-04T23:36:00.002-07:002014-08-04T23:36:14.881-07:00The Fame Trap<div dir="ltr" style="text-align: left;" trbidi="on">
The other day I was speaking with a group of interns about the differences between the academic and industrial career paths. One of them mentioned that when you join a company like Google, you lose your identity -- that is, people outside the company may not know much about what you do or work on. I like to think of it like getting assimilated into the Borg. This is a concern I hear a lot from grad students.<br />
<br />
First off, this is absolutely true. Unless you work really hard at it, being in industry (not counting industrial research labs, of course) does not afford you as many opportunities to stay visible in the research community. No big surprise here -- at a company like Google, your job isn't to publish papers, it's to build products. You <i>can</i> publish papers, serve on program committees, and go to conferences -- but when academic research not your main job, doing those things isn't necessarily a priority.<br />
<br />
I think many grad students get fixated on this idea of cultivating their academic profile and tend to make career decisions that build on that, to the exclusion of some other ways in which they could have a mark on the world. (This absolutely happened to me.) As an academic, your entire career is focused, to some degree, on building and maintaining your personal brand. In my experience, though, the "fame" you enjoy as an academic is on a fairly small scale, and it takes a tremendous amount of energy to perpetuate. That is, there are many reasons for wanting to pursue an academic career, but I would argue that achieving prestige in the research community isn't a particularly good one.<br />
<br />
Let's keep things in perspective -- renown in the academic world is on a tiny scale. Take the systems community: a typical systems conference will have no more than about 400 attendees. Let's assume that roughly 10% of the people in the community (that matter!) are actually going to the major conferences -- so we're talking (generously) on the order of 10,000 people or so who might be active in the systems community at any given time.<br />
<br />
I'm sorry, but being "famous" in a tight-knit community of O(10K) academics ain't really being famous. That's nowhere near the level of Kanye, or even Neil deGrasse Tyson. In fact, I can't name a single academic computer scientist who enjoys that level of fame. Maybe Alan Turing, but his fame is largely posthumous. There are the rare academics who are well-known across CS -- David Patterson comes to mind -- but even he's not exactly a household name. (Unless your household involves a lot of dinnertime conversations about disk arrays and processor architecture.)<br />
<br />
As a grad student, it's pretty easy to fall into the fame trap, and I speak from experience. When I finished my PhD, I was pretty much dead set on having an academic career, because that seemed to be the most glamorous, high-profile career path at the time. (Keep in mind that when I finished my PhD in 2002, I had an offer from pre-IPO Google, and could have been something like employee #400. Now I'm just employee #40,000.) I was enamored with the prestige of being a professor. I dreamt of running my own lab, having my own students, being as "famous" as my advisor. And of course, from having been in grad school for so long, building up my academic profile was pretty much the only world I knew.<br />
<br />
What I didn't realize at the time was how much work it would be to maintain an academic reputation. To be visible, and stay visible, in the research community means going to countless conferences, serving on program committees and panels, visiting other universities to give talks, and of course publishing as many papers as you possibly can. Getting tenure is driven in large part by how well known you are and how much "impact" you're having. If you fail to do these things, your stature in the community slips pretty quickly, unless you are <i>really</i> well-established and can afford to just show your face from time to time. (Junior faculty need not apply.)<br />
<br />
I see this all the time in my academic colleagues. They travel constantly -- one or two trips per month is typical. They say yes to a ridiculous number of committees, advisory boards, whatever. They like to "complain" about the amount of travel and committee work they do, but I'm sure they all realize that they can't really stop doing it, lest they stop getting invited to do these things. (Kind of a strange vicious cycle, that.) It's like being in a small-time folk band that has to tour constantly to keep paying the bills -- you never get a break.<br />
<br />
I applaud my academic colleagues who can still do this. For me, personally, I never really enjoyed it, and I found it wasn't worth the sacrifice just to maintain the status quo of my academic reputation. Once I had kids, I really started to appreciate the toll it was having on my family to be out of town so often, and I started to realize that maybe I had my priorities all wrong.<br />
<br />
These days I still enjoy being part of the academic community, but in a more selective way. I like to go to occasional conferences and serve on PCs that are very closely aligned with my area, because I learn a lot about what's going on in the research world. It's also a good way to recruit interns and full-time hires, and of course I have lots of academic friends I like to meet up with and have beers with. I'll admit I still like giving talks from time to time. I've done very little publishing since leaving academia, but that's by choice -- I'm spending my time on things that are more important (to me) than writing more papers.<br />
<br />
None of this is to say that academia can't be a wonderful career path, but I think chasing academic fame is not the best reason to go down that path. I wish I had known that when I was finishing my PhD.<br />
<br /></div>
Unknownnoreply@blogger.com20tag:blogger.com,1999:blog-9186457242428335144.post-48356360464147585972014-05-31T19:00:00.001-07:002014-05-31T19:00:46.960-07:00The NCSSM 2014 commencement address<div dir="ltr" style="text-align: left;" trbidi="on">
<div class="tr_bq">
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)!</div>
<div class="tr_bq">
<br /></div>
<div class="tr_bq">
NCSSM is dear to my heart and those two years were a transformative time in my life. I've <a href="http://matt-welsh.blogspot.com/2012/10/ncssm-and-how-it-saved-my-life.html">blogged before about how my time at S&M saved my life</a> -- it is difficult to overstate how important the place was to my formative years. (Actually I think I'm still "forming".)</div>
<br />
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:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-8EAB7ph-tGE/U4qGi9wAdVI/AAAAAAABj20/qS0ZbPU8CpE/s1600/10353245_10101452254257621_2027594215041274878_o.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-8EAB7ph-tGE/U4qGi9wAdVI/AAAAAAABj20/qS0ZbPU8CpE/s1600/10353245_10101452254257621_2027594215041274878_o.jpg" height="292" width="400" /></a></div>
<br />
So much for being unique.<br />
<br />
The school live-streamed the event and I was surprised to find a video of my speech online soon after it was over. <a href="http://new.livestream.com/ncssmlivestream/commencement2014/videos/52485109">Watch here at your own peril.</a><br />
<br />
Below I'm posting my prepared speech (which is not exactly the same as the one I actually gave).<br />
<br />
<blockquote>
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! </blockquote>
<blockquote>
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.</blockquote>
<blockquote>
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.</blockquote>
<blockquote>
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.</blockquote>
<blockquote>
NCSSM taught me the single most important lesson I’ve ever learned in my life, and I want to share it with you.</blockquote>
<blockquote>
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.</blockquote>
<blockquote>
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.</blockquote>
<blockquote>
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!</blockquote>
<blockquote>
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.</blockquote>
<blockquote>
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.</blockquote>
<blockquote>
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.</blockquote>
<blockquote>
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.</blockquote>
<blockquote>
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.</blockquote>
<blockquote>
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.</blockquote>
<blockquote>
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.</blockquote>
<blockquote>
So never stop looking. That’s it. Pretty simple, right? Never stop looking. You never know what you might find.</blockquote>
<blockquote>
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.</blockquote>
<blockquote>
Thank you very much, and congratulations to the class of 2014!</blockquote>
<br />
<br />
<br />
<br /></div>
Unknownnoreply@blogger.com8tag:blogger.com,1999:blog-9186457242428335144.post-43415795924487242812014-05-07T22:58:00.001-07:002014-05-07T22:58:08.430-07:00The Google career path, Part 2: Starting new projects<div dir="ltr" style="text-align: left;" trbidi="on">
In my last blog post, I talked about <a href="http://matt-welsh.blogspot.com/2014/05/the-google-career-path-part-1-getting.html">what it's like to get started at Google as a new engineer</a>. In this post, I'll talk about how new projects get started.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<b>How my project got its start</b><br />
<b><br /></b>
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 <a href="https://developer.chrome.com/multidevice/data-compression">Chrome Mobile data compression proxy</a>, 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.<br />
<br />
When I <a href="http://matt-welsh.blogspot.com/2011/05/what-im-working-on-at-google-making.html">started the team</a> 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 <a href="http://www.webpagetest.org/mobile">Webpagetest</a> 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 <a href="https://developers.google.com/speed/pagespeed/">PageSpeed</a>, to see what kind of gains could be had.<br />
<br />
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 <a href="http://www.google.com/intl/en_us/chrome/browser/mobile/">Chrome Mobile</a> 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.<br />
<br />
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 <a href="http://chrome.blogspot.com/2014/01/more-web-more-savings-with-chrome-for.html">launch it to everyone</a>. Boom!<br />
<br />
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).<br />
<br />
<b>Does this generalize?</b><br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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).<br />
<br />
<b>What about 20% time?</b><br />
<br />
<a href="http://www.wired.com/2013/08/20-percent-time-will-never-die/">Much has been written</a> about Google's "20% time", whereby engineers are allowed to work on projects unrelated to their main job. (You can't do just <i>anything</i> 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.<br />
<br />
Gmail f<a href="http://googlepress.blogspot.com/2004/04/google-gets-message-launches-gmail.html">amously started</a> as a 20% project. (The original press release was ironically posted on April 1, 2004, but it was not actually an April Fools' joke!)<br />
<br />
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 <a href="http://www.geekwire.com/2012/tis-the-season-google-giving/">internal platform for employees making charitable contributions</a>, called "G-Give". Another contributes to the <a href="http://googleblog.blogspot.com/2014/01/introducing-our-smart-contact-lens.html">smart contact lens</a> 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.)<br />
<br />
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.<br />
<br />
But promotions are the subject of my next blog post, so I'll leave it at that.<br />
<br /></div>
Unknownnoreply@blogger.com8tag:blogger.com,1999:blog-9186457242428335144.post-83243508642967499772014-05-01T20:38:00.000-07:002014-05-01T20:38:38.195-07:00The Google career path, part 1: Getting started<div dir="ltr" style="text-align: left;" trbidi="on">
Apart from how to get a job at Google (<a href="http://matt-welsh.blogspot.com/2014/01/getting-job-at-google-for-phd-students.html">which I have previously blogged about</a>), 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.<br />
<br />
(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.)<br />
<br />
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.<br />
<br />
<b>Before you join: The team match</b><br />
<b><br /></b>
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 <a href="http://matt-welsh.blogspot.com/2011/05/what-im-working-on-at-google-making.html">mobile Web browsing faster</a> and <a href="https://developer.chrome.com/multidevice/data-compression">more efficient</a>.<br />
<br />
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 <a href="https://peering.google.com/about/ggc.html">content delivery network for YouTube</a>, 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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
<b>The starter project</b><br />
<b><br /></b>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.<br />
<br />
The first week on the job is typically spent in orientation, which is usually done at the headquarters in Mountain View. I <a href="http://matt-welsh.blogspot.com/2010/07/first-week-at-google.html">blogged about my first week at Google</a> 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.<br />
<br />
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.<br />
<br />
<b>Taking ownership</b><br />
<b><br /></b>
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.<br />
<br />
To give a concrete example, one of the (relatively) recent PhD hires on my team, <a href="https://plus.google.com/103108020588016397731">Michael Buettner</a>, started out by investigating the size and quality tradeoff for the image transcoding parameters we were using in the <a href="https://developer.chrome.com/multidevice/data-compression">Chrome Mobile data compression proxy</a>. 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.<br />
<br />
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.<br />
<br />
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.</div>
Unknownnoreply@blogger.com6tag:blogger.com,1999:blog-9186457242428335144.post-18939077431490895532014-02-28T13:20:00.002-08:002014-02-28T13:20:54.896-08:00Taking the "Hot" out of "Hot Topics" workshops<div dir="ltr" style="text-align: left;" trbidi="on">
I just got back from <a href="http://www.hotmobile.org/2014">HotMobile 2014</a> (for which I was the general chair). HotMobile is the mobile systems community's "hot topics" workshop, held annually as a forum for (according to the <a href="http://www.hotmobile.org/2014/index.php?id=calls">Call for Papers</a>) "position papers containing highly original ideas" and which "propose new directions of research" or "advocate non-traditional approaches". It's a small workshop (we had about 95 people this year) and the paper submissions are short -- 6 pages, rather than the regular 14.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://1.bp.blogspot.com/-b8BkPP3hitc/UxD9iYXzPeI/AAAAAAABfh8/QgBd7MHeLV4/s1600/ps_5985562024104183778.jpeg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://1.bp.blogspot.com/-b8BkPP3hitc/UxD9iYXzPeI/AAAAAAABfh8/QgBd7MHeLV4/s1600/ps_5985562024104183778.jpeg" height="235" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The HotMobile'14 poster and demo session.<br />Look how happy those mobile systems researchers are!</td></tr>
</tbody></table>
Overall, the workshop was great -- lots of good discussions, good talks, interesting ideas. And yet, every time I attend one of these "hot topics" workshops, I end up feeling that the papers fall well short of this lofty goal. This is not limited to the mobile community -- the <a href="http://matt-welsh.blogspot.com/2013/05/what-i-wish-systems-researchers-would.html">HotOS community has a similar problem</a> as well.<br />
<br />
This has bugged me for a long time, since it often feels as though there is no venue for doing "out of the box" work that is intended to look out five or ten years -- rather than just things that are incremental but not yet ready for publication in a major conference like SOSP or MobiSys. I also have fond memories of HotOS in the late 1990s in which it felt as though many of the papers were there to shake up the status quo and put forward a strong position.<br />
<br />
What I've now come to realize is that <b>there is a tremendous value in having a small workshop for preliminary (and often incremental) results</b>. The community obviously feels that such a venue is useful, despite its lack of "hotness" -- we had a record number of attendees this year, and (I believe) a near-record number of submissions.<br />
<br />
And after all, the main reasons to attend any workshop are the discussions and networking -- not the papers.<br />
<br />
The problem is that we insist on calling this a "hot topics" workshop and pretend that it's about far-out ideas that could not be published elsewhere. Instead, I think we should be honest that HotMobile (and HotOS, HotNets, etc.) are really for three kinds of papers:<br />
<ol style="text-align: left;">
<li><b>Preliminary work on a new project</b> which is not yet ready for a major conference. Getting early feedback on a new project is often very useful to researchers, so they know if they are barking up the right trees.<br /><br />An example of this from this year is the <a href="http://www.hotmobile.org/2014/papers/hotmobile_final/hotmobile2014-final15.pdf">CMU paper on QuiltView,</a> which proposes allowing users to pose real-time queries ("How is the weather down at the beach in Santa Barbara?") and get back real-time video snippets (from users wearing Google Glass!) in reply. This work is no where near mature enough for a full conference, and I hope the authors gained something from the paper reviews and discussion at the workshop to shape their future direction.<br /></li>
<li><b>An incremental, and possibly vestigial, step</b>, towards the next major conference paper on a topic. Many such papers are simply not big enough ideas for a full conference paper, but make a nice "short paper" for the sake of getting some idea out there.<br /><br />One example from this year is <a href="http://www.hotmobile.org/2014/papers/hotmobile_final/hotmobile2014-final42.pdf">this paper on the dangers of public IPs for LTE devices</a>. This isn't something that's going to turn into a longer, more pithy paper later on, but is probably worth reporting.<br /></li>
<li>The <b>odd wacky paper</b> that falls under the "hot topics" rubric. These are increasingly rare. About the only example from this year is this <a href="http://synrg.csl.illinois.edu/papers/buzz.pdf">Duke paper on adding smart capabilities to childrens' toys with smartphones</a> -- but the idea is not <i>that</i> radical.</li>
</ol>
Last year at SOSP, there was a one-day workshop called <a href="http://sigops.org/sosp/sosp13/trios.html">TRIOS</a> ("Timely Results in Operating Systems") which was an informal venue for preliminary work -- exactly to provide an outlet for papers in the first two categories above. At least TRIOS was honest about its intent, so nobody attending could be disappointed that the papers weren't "hot" enough.<br />
<br />
So, my humble proposal is to rename the workshop "ColdMobile" and, just to be cheeky, hold it at a ski resort in the winter.<br />
<br />
<br /></div>
Unknownnoreply@blogger.com7tag:blogger.com,1999:blog-9186457242428335144.post-16900458310242106292014-01-30T22:45:00.003-08:002014-01-30T22:50:16.984-08:00Getting a job at Google for PhD Students<div dir="ltr" style="text-align: left;" trbidi="on">
I happen to sit on one of the hiring committees at Google, which looks at interview packets and makes a recommendation about whether we should extend an offer or not. So I've read a lot of packets, and have seen some of the ways in which applicants succeed or fail to get an offer. Ph.D. students, in particular, tend to get tripped up by the Google interview process, so I thought I'd offer some advice.<br />
<br />
While I can't be certain, I imagine this same advice would apply to other companies which have a similar interview process that focuses on coding and algorithms.<br />
<br />
(Disclaimer: This is all my personal opinion, and nothing I'm saying here is sanctioned or recommended by Google in any way. In fact, it might be totally wrong. Take it with a grain of salt.)<br />
<br />
<b>Google's interview process</b><br />
<b><br /></b>
Google uses a fairly typical industry interview process: Candidates go through one or two phone screens (or possibly an on-campus interview), and if they do well they are brought on campus for a full interview loop. Each interview is an hour and consists largely of problem solving and coding on the whiteboard. Sometimes a laptop is used.<br />
<br />
This same process is used for <i>all</i> software engineering positions, regardless of level: undergrads, PhD students, and seasoned industry candidates all get the same style of interview. I had to go through this interview process upon joining Google as a professor. PhD-level candidates will generally spend one interview slot discussing their thesis work, and the questions may be more "researchy", but by and large it's the same for everyone.<br />
<br />
<b>The problem</b><br />
<b><br /></b>
Ph.D. students often tend to do <i>worse</i> on coding interviews than, say, bachelors' or masters' level candidates. Why? <b>Doing a Ph.D. simply does not train you in professional software development skills</b>, and that is (primarily) what a Google interview tests for. Undergrads, paradoxically, often do better because (a) they may have done internships at companies writing code, and (b) have practiced for this style of interview in the past.<br />
<br />
There is a widespread belief that doing a Ph.D. somehow elevates you above the need to demonstrate fundamental algorithms and coding skills. Having a Ph.D. from Berkeley is awesome, but you still gotta be able to write good, clean code.<br />
<br />
Also, part of the long process of doing a Ph.D. means you get hyper-specialized, so you get farther away from the "basics". Many of the Google interview questions touch on topics you probably first encountered (and mastered) as a sophomore or junior in college. I don't know about you, but I never dealt with binary search trees or graph connectivity problems directly during my Ph.D. and subsequent years as a faculty member. (Then again I'm just a systems guy, so the most sophisticated data structure I ever deal with is a hash table.)<br />
<br />
<b>Why the basics matter</b><br />
<div>
<br /></div>
<div>
Being at Google means writing production-quality software. We don't have "research labs" where people primarily build prototypes or write papers. I have <a href="http://matt-welsh.blogspot.com/2011/01/does-google-do-research.html">written about Google's hybrid research model</a> elsewhere -- also see <a href="http://cacm.acm.org/magazines/2012/7/151226-googles-hybrid-approach-to-research/fulltext">this CACM article</a> for more. While there are exceptions, by and large being at Google means being on a product team building and launching real products. That is even true of the more far-flung projects like self-driving cars and high-altitude Internet balloons. The quality and professionalism of the code you develop matters a great deal.</div>
<div>
<br /></div>
<div>
Doing a Ph.D. generally trains you for building research prototypes. There is a vast difference between this and writing production-quality code. First of all, it's not good enough for the code to make sense -- or be maintainable -- only by you or a small number of collaborators. Adherence to good design, avoiding overcomplicated code, conforming to style guidelines, etc. are all super important. In addition, you have to really concern yourself with robustness, scalability, testability, and performance. Corner cases that aren't interesting for publishing your next paper can't be overlooked.</div>
<div>
<br /></div>
<div>
Most of these skills can only be developed by working with a professional software development team. Research and class projects don't give you a chance to develop these skills. Undergrads gain these skills largely through internships. Unfortunately, most PhD students do internships at research labs, which may or may not provide much opportunity to build production-quality software.</div>
<div>
<br /></div>
<div>
<b>Advice for grad students</b></div>
<div>
<b><br /></b></div>
<div>
If you're interviewing at Google, bone up on your basic algorithms and data structures. Go dust off that sophomore-level textbook and try to page it back in. I also <b>highly recommend</b> the book <a href="http://www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/098478280X">Cracking the Coding Interview</a>, which gives the best description I have seen of Google-style interviews - it was written by a former Googler.</div>
<div>
<br /></div>
<div>
Don't go in with the attitude that you're above all this. Roll up your sleeves and show them what you've got. I know it may feel silly being asked what seem like basic CS questions, but if you're really as good as you think you are, you should knock them out of the park. (Keep in mind that the questions get harder the better you are doing, so no matter what, you will probably feel like crap at the end of the day.)</div>
<div>
<br /></div>
<div>
Every line of code you write on the whiteboard will get written up as part of the interview packet. Make it squeaky clean. Initialize variables. Use semicolons. Don't forget your constructors. Although writing sloppy pseudocode to get your meaning across might seem adequate (after all, we're all professionals here, aren't we?), attention to detail matters. Code in C++ or Java, which shows maturity. If you can only code in Python or bash shell, you're going to have trouble. If you make the slightest suggestion of wanting to code in Haskell or Lisp, the interviewer will push a hidden button which opens a trap door, dropping you into a bottomless pit. (Just kidding.)</div>
<div>
<br /></div>
<div>
Never, <b>ever</b> suggest you are a "C++ expert", either on your resume or in person. You are not.</div>
<div>
<br /></div>
<div>
Unfortunately, Google interviews tend to be a bit one-sided and you will not have as much opportunity to learn about Google (and what projects you might be working on) as you would like. If you do get an offer, you'll have more opportunities to come back and ask those questions. Google is notoriously secretive, so you have to trust me that there are plenty of cool things to work on.</div>
<div>
<br /></div>
<div>
Finally: Remember that the content of the <i>interview</i> has nothing to do with the kind of <i>projects</i> you would work on here. You're not going to get hired by Google and be asked to implement depth-first-search or reverse a linked list -- trust me on that. I'm pretty sure we have library routines for those already.</div>
</div>
Unknownnoreply@blogger.com38tag:blogger.com,1999:blog-9186457242428335144.post-45126921405798488452014-01-21T22:39:00.001-08:002014-01-21T22:39:33.053-08:00Your Field Guide to Industrial Research Labs<div dir="ltr" style="text-align: left;" trbidi="on">
There are a lot of different kinds of industrial research organizations out there. Identifying them can be tricky, so I've compiled this field guide to help you out.<br />
<br />
<b>The Patent Factory Research Lab</b><br />
<b><br /></b>
This is the classic model of research lab, and the main model that existed when I was a grad student in the late 1990s. Many of these labs no longer exist, or have transformed into one of the models below. Generally attached to a big company, this style of research lab primarily exists to bolster the parent company's patent portfolio. A secondary mission is to somehow inform the long-term product roadmap for the parent company, which may or may not be successful, depending on whether the research lab is located 50 miles or a mere 15 miles away from any buildings in which actual product teams work.<br />
<br />
<i>How you know you're visiting this style of lab: </i>The main decoration in researcher's offices are the little paperweights they get for every 20 patents they file.<br />
<br />
<b>The Academic Department inside of a Company Research Lab</b><br />
<b><br /></b>
This model is somewhat rare but it does exist, and a couple of companies have done a superb job building up a lab full of people who would really like to have been professors but who really don't like teaching or getting too close to undergraduates. This style of research lab focuses on cranking out paper after paper after paper and padding the ranks of every program committee in sight with its own members. Product impact is usually limited to demos, or the occasional lucky project which gets taken in by a product team and then ripped to shreds until it no longer resembles the original research in any way.<br />
<br />
<i>How you know you're visiting this style of lab:</i> It feels just like grad school, except everyone gets their own office, and there are a lot more Windows desktops than you would normally expect to see.<br />
<br />
<b>The Why Are We Still Here, Let's Hope The CEO Doesn't Notice Research Lab</b><br />
<b><br /></b>
This type of research lab exists only because the C-level executives have either misplaced it or forgotten it exists. Researchers here are experts in flying under the radar, steering clear of anything that might generate the slightest amount of media coverage lest they blow their cover. When asked what they are working on, they generally mumble something about "the cloud" which grants them another two-year reprieve until another VP-level review comes around, at which time everyone scrambles to put together demos and PowerPoint decks to look like they've been busy.<br />
<br />
<i>How you know you're visiting this style of lab: </i>Nobody has the slightest idea what's happening in the actual research community, and the project titles sound auto-generated.<br />
<b><br /></b>
<b>The It's We-Could-Tell-You-But-We'd-Have-To-Kill-You Research Lab</b><br />
<b><br /></b>
This type of lab deals exclusively in classified defense contracts. These labs all have innocuous-sounding names which evoke the Cold War and bygone days when it was acceptable, and even encouraged, to smoke a pipe while working in the lab. Projects are done under contract from some branch of the military and generally involve satellites, nuclear warheads, lasers, or some combination of the above. On the plus side, this is the type of lab where you are most likely to encounter alien technology or invent time travel.<br />
<br />
<i>How you know you're visiting this style of lab: </i>All project names are comprised of inscrutable acronyms such as "JBFM MAXCOMM"; nobody seems to have a sense of humor.<br />
<br />
<b>The "We Have a Research Lab Too" Research Lab</b><br />
<b><br /></b>
This is the model exemplified by startup companies who are feeling jealous that they don't have enough Ph.D.'s working for them and feel the need to start "Doge.com Research" to make their mark on the world. This generally happens the first time such a company hires an ex-academic and makes the mistake of putting them in any kind of leadership role. Projects in this kind of lab aren't that different from regular work on the product teams, apart from the expectation that launching anything will take three times longer than a non-research team would be able to do.<br />
<br />
<i>How you know you're visiting this style of lab:</i> Hoodies with the word "Research" on them; free lunch.<br />
<br />
<br /></div>
Unknownnoreply@blogger.com13tag:blogger.com,1999:blog-9186457242428335144.post-16322476736138014562013-08-18T16:09:00.002-07:002013-08-18T16:14:17.607-07:00Rewriting a large production system in Go<div dir="ltr" style="text-align: left;" trbidi="on">
My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in <a href="http://golang.org/">Go</a>. 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.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://1.bp.blogspot.com/-ZMZJ61vE1nQ/UhFOJ_moA2I/AAAAAAABWKw/qWJ2OZOBt8o/s1600/go-at-google-io-2011-videos_gopher.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="320" src="http://1.bp.blogspot.com/-ZMZJ61vE1nQ/UhFOJ_moA2I/AAAAAAABWKw/qWJ2OZOBt8o/s320/go-at-google-io-2011-videos_gopher.jpg" width="240" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Plus, the Go language has a cute mascot ... awwww!</td></tr>
</tbody></table>
<b>Why rewrite?</b><br />
<b><br /></b>
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 would be extremely challenging on this large, shared codebase. This is not a ding to the original developers -- it is just a fact that when certain design decisions become ossified, it becomes more difficult to rethink them, especially when multiple teams are sharing the code.<br />
<br />
Before doing the rewrite, we realized we needed only a small subset of the functionality of the original system -- perhaps 20% (or less) of what the other projects were doing with it. We were also looking at making some radical changes to its core logic, and wanted to experiment with new features in a way that would not impact the velocity of our team or the others using the code. Finally, the cognitive burden associated with making changes to any large, shared codebase is unbearable -- almost any change required touching lots of code that the developer did not fully understand, and updating test cases with unclear consequences for the other users of the code.<br />
<br />
So, we decided to fork off and do a from-scratch rewrite. The bet we made was that taking an initial productivity hit during the initial rewrite would pay off in droves when we were able to add more features over time. It has also given us an opportunity to rethink some of the core design decisions of our system, which has been extremely valuable for improving our own understanding of its workings.<br />
<br />
<b>Why Go?</b><br />
<b><br /></b>
I'll admit that at first I was highly skeptical of using Go. This production system sits directly on the serving path between users and their content, so it has to be fast. It also has to handle a large query volume, so CPU and memory efficiency are key. Go's reliance on garbage collection gave me pause (pun intended ... har har har), given how much pain Java developers go through to manage their memory footprint. Also, I was not sure how well Go would be supported for the kind of development we wanted to do inside of Google. Our system has lots of dependencies, and the last thing I wanted was to have to reinvent lots of libraries in Go that we already had in C++. Finally, there was also simply the fear of the unknown.<br />
<br />
My whole attitude changed when <a href="http://www.michaelpiatek.com/">Michael Piatek</a> (one of the star engineers in the group) sent me an initial cut at the core system rewrite in Go, the result of less than a week's work. Unlike the original C++ based system, <b>I could actually read the code</b>, even though I didn't know Go (yet). The #1 benefit we get from Go is the lightweight concurrency provided by <a href="http://golang.org/doc/effective_go.html#goroutines">goroutines</a>. Instead of a messy chain of dozens of asynchronous callbacks spread over tens of source files, the core logic of the system fits in a couple hundred lines of code, all in the same file. You just read it from top to bottom, and it makes sense.<br />
<br />
Michael also made the observation that <b>Go is a language designed for writing Web-based services.</b> Its standard libraries provide all of the machinery you need for serving HTTP, processing URLs, dealing with sockets, doing crypto, processing dates and timestamps, doing compression. Unlike, say, Python, Go is a compiled language and therefore very fast. Go's modular design makes for beautiful decomposition of code across modules, with clear explicit dependencies between them. Its incremental compilation approach makes builds lightning fast. Automatic memory management means you never have to worry about freeing memory (although the usual caveats with a GC-based language apply).<br />
<br />
<b>Being terse</b><br />
<br />
Syntactically, Go is very succinct. Indeed, the Go style guidelines encourage you to write code as tersely as possible. At first this drove me up the wall, since I was used to using long descriptive variable names and spreading expressions over as many lines as possible. But now I appreciate the terse coding approach, as it makes <i>reading and understanding</i> the code later much, much easier.<br />
<br />
Personally, I really like coding in Go. I can get to the point without having to write a bunch of boilerplate just to make the compiler happy. Unlike C++, I don't have to split the logic of my code across header files and .cc files. Unlike Java, you don't have to write anything that the compiler can infer, including the types of variables. Go feels a lot like coding in a lean scripting language, like Python, but you get type safety for free.<br />
<br />
Our Go-based rewrite is 121 Go source files totaling about 21K lines of code (including comments). Compare that to the original system, which was 1400 C++ source files with 460K lines of code. (Remember what I said about the new system implementing a small subset of the new system's functionality, though I do feel that the code size reduction is disproportionate to the functionality reduction.)<br />
<br />
<b>What about ramp-up time?</b><br />
<b><br /></b>
Learning Go is easy coming from a C-like language background. There are no real surprises in the language; it pretty much makes sense. The standard libraries are <a href="http://golang.org/pkg/">very well documented</a>, and there are plenty of <a href="http://tour.golang.org/#1">online tutorials</a>. None of the engineers on the team have taken very long at all to come up to speed in the language; heck, even one of our interns picked it up in a couple of days.<br />
<br />
Overall, the rewrite has taken about 5 months and is already running in production. We have also implemented 3 or 4 major new features that would have taken <b>much longer</b> to implement in the original C++ based system, for the reasons described above. I estimate that our team's productivity has been improved by at least a factor of ten by moving to the new codebase, and by using Go.<br />
<br />
<b>Why not Go?</b><br />
<b><br /></b>
There are a few things about Go that I'm not super happy about, and that tend to bite me from time to time.<br />
<br />
First, you need to "know" whether the variable you are dealing with is an interface or a struct. Structs can implement interfaces, of course, so in general you tend to treat these as the same thing. But when you're dealing with a struct, you might be passing by reference, in which the type is <span style="font-family: Courier New, Courier, monospace;">*myStruct,</span> or you might be passing by value, in which the type is just <span style="font-family: Courier New, Courier, monospace;">myStruct</span>. If, on the other hand, the thing you're dealing with is "just" an interface, you never have a pointer to it -- an interface <i>is</i> a pointer in some sense. It can get confusing when you're looking at code that is passing things around without the * to remember that it might actually "be a pointer" if it's an interface rather than a struct.<br />
<br />
Go's type inference makes for lean code, but requires you to dig a little to figure out what the type of a given variable is if it's not explicit. So given code like:<br />
<blockquote class="tr_bq">
<span style="font-family: Courier New, Courier, monospace;">foo, bar := someFunc(baz) </span></blockquote>
You'd really like to know what <span style="font-family: Courier New, Courier, monospace;">foo</span> and <span style="font-family: Courier New, Courier, monospace;">bar</span> actually are, in case you want to add some new code to operate on them. If I could get out of the 1970s and use an editor other than vi, maybe I would get some help from an IDE in this regard, but I staunchly refuse to edit code with any tool that requires using a mouse.<br />
<br />
Finally, Go's liberal use of interfaces allows a struct to implement an interface "by accident". You never have to explicitly declare that a given struct implements a particular interface, although it's good coding style to mention this in the comments. The problem with this is that it can be difficult to tell when you are reading a given segment of code whether the developer intended for their struct to implement the interface that they appear to be projecting onto it. Also, if you want to refactor an interface, you have to go find all of its (undeclared) implementations more or less by hand.<br />
<br />
Most of all I find coding in Go <b>really, really fun</b>. This is a bad thing, since we all know that "real" programming is supposed to be a grueling, painful exercise of fighting with the compiler and tools. So programming in Go is making me soft. One day I'll find myself in the octagon ring with a bunch of sweaty, muscular C++ programmers bare-knuckling it out to the death, and I just know they're going to mop the floor with me. That's OK, until then I'll just keep on cuddling my stuffed gopher and running <span style="font-family: Courier New, Courier, monospace;">gofmt</span> to auto-intent my code.<br />
<br />
<i>ObDisclaimer: Everything in this post is my personal opinion and does not represent the view of my employer.</i></div>
Unknownnoreply@blogger.com53tag:blogger.com,1999:blog-9186457242428335144.post-33265985752582062672013-07-11T22:20:00.004-07:002013-07-11T22:30:18.733-07:00Does the academic process slow innovation?<div dir="ltr" style="text-align: left;" trbidi="on">
I've been wondering recently whether the extended, baroque process of doing research in an academic setting (by which I mean either a university or an "academic style" research lab in industry) is doing more harm than good when it comes to the pace of innovation.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://4.bp.blogspot.com/--trURSJLxDI/Ud-RN4ik-rI/AAAAAAABQbE/E6K9hloLTcs/s1600/tumblr_mi4afkjBRT1rk8o0xo1_1280.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="300" src="http://4.bp.blogspot.com/--trURSJLxDI/Ud-RN4ik-rI/AAAAAAABQbE/E6K9hloLTcs/s400/tumblr_mi4afkjBRT1rk8o0xo1_1280.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">From http://academicnegativity.tumblr.com/</td></tr>
</tbody></table>
Prior to moving to industry, I spent my whole career as an academic. It took me a while to get used to how <i>fast</i> things happen in industry. My team, which is part of Chrome, does a new major release <b>every six weeks.</b> This is head-spinningly fast compared to academic projects. Important decisions are made on the order of days, not months. Projects are started up and executed an order of magnitude faster than it would take a similarly-sized academic research group to get up to speed.<br />
<br />
This is not just about having plenty of funding (although that is part of it). It is also about what happens when you abandon the trappings of the academic process, for which the timelines are glacial:<br />
<div style="text-align: left;">
</div>
<ul>
<li>A three month wait (typically) to get a decision on a conference submission, during which time you are not allowed to submit similar work elsewhere.</li>
<li>A six month wait on hearing back on a grant proposal submission.</li>
<li>A year or more wait for a journal publication, with a similar restriction on parallel submissions.</li>
<li>Five plus years to get a PhD.</li>
<li>Possibly one or two years as a postdoc.</li>
<li>Six to eight years to get tenure.</li>
<li>A lifetime of scarring as the result of the above. (Okay, I'm kidding. Sort of.)</li>
</ul>
This is not a problem unique to computer science of course. In the medical field, the <a href="http://scientopia.org/blogs/drugmonkey/2012/02/14/updating-the-age-of-first-nih-r01-award-trends-flatlining/">average age at which a PI receives their first NIH R01 grant is 44 years.</a> Think about that for a minute. That's 23-some-odd years <i>after graduation</i> before an investigator is considered an "independent" contributor to the research field. Is this good for innovation?<br />
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
<b>Overhead</b></div>
<div style="text-align: left;">
<b><br /></b></div>
<div style="text-align: left;">
Part of the problem is that the academic process is full of overheads. Take a typical conference program committee for example. Let's say the committee has 15 members, each of whom has 30 papers to review (this is pretty average, for good conferences at least). Each paper takes at least an hour to review (often more) - that's the equivalent of at least 4 work days (that is, assuming academics work only 8 hours a day ... ha ha!). Add on two more full days (minimum) for the program committee meeting and travel, and you're averaging about a full week of work for each PC member. Multiply by 15 -- double it for the two program co-chairs -- and you're talking about around 870 person-hours combined effort to decide on the 25 or so papers that will appear in the conference. <b>That's 34 person-hours of overhead per paper. </b>This doesn't count any of the overheads associated with actually organizing the conference -- making the budget, choosing the hotel, raising funds, setting up the website, publishing the proceedings, organizing the meals and poster sessions, renting the projectors ... you get my point.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
<b>The question is, does all of this time and effort produce (a) better science or (b) lead to greater understanding or impact?</b> I want to posit that the answer is no. This process was developed decades ago in a pre-digital era where we had no other way to disseminate research results. (Hell, it's gotten much easier to run a program committee now that submissions are done via the web -- it used to be you had to print out 20 copies of your paper and mail them to the program chair who would mail out large packets to each of the committee members.)</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
But still, we cling to this process because it's the only way we know how to get PhD students hired as professors and get junior faculty tenured -- any attempt to buck the trend would no doubt jeopardize the career of some young academic. It's sad.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
<b>How did we get here?</b></div>
<div style="text-align: left;">
<b><br /></b></div>
<div style="text-align: left;">
Why do we have these processes in the first place? The main reason is competition for scarce resources. Put simply, there are <b>too many academics</b>, and <b>not enough funding</b> and <b>not enough paper-slots in good conference venues</b>. Much has been said about the sad state of public funding for science research. Too many academics competing for the same pool of money means longer processes for proposal reviews and more time re-submitting proposals when they get rejected.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
As far as the limitation on conferences goes, you can't create more conferences out of thin air, because people wouldn't have time to sit on the program committees and travel to all of them (ironic, isn't it?). Whenever someone proposes a new conference venue there are groans of "but how will we schedule it around SOSP and OSDI and NSDI and SIGCOMM?!?" - so forget about that. Actually, I think the best model would be to adopt the practice of some research communities and have <b>one big mongo conference</b> every year that <i><b>everybody</b></i> goes to (ideally in Mexico) and have USENIX run it so the scientists can focus on doing science and leave the conference organization to the experts. But I digress.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
The industrial research labs don't have the same kind of funding problem, but they still compete for paper-slots. And I believe this inherently slows everything down because you can't do new research when you have to keep backtracking to get that paper you spent so many precious hours on finally published after the third round of rejections with "a strong accept, two weak accepts, and a weak reject" reviews. It sucks.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
<b>Innovative != Publishable</b></div>
<div style="text-align: left;">
<b><br /></b></div>
<div style="text-align: left;">
My inspiration for writing this post came from the amazing pace at which innovation is happening in industry these days. The most high-profile of these are crazy "moon shot" projects like <a href="http://www.spacex.com/">SpaceX</a>, <a href="http://23andme.com/">23andme</a>, and Google's <a href="http://www.google.com/loon/">high-altitude balloons to deliver Internet access to entire cities</a>. But there are countless other, not-as-sexy innovations happening every day at companies big and small, just focused on changing the world, rather than writing papers about it.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
I want to claim that even with all of their resources, had these projects gone down the conventional academic route -- writing papers and the like -- they would have never happened. No doubt if a university had done the equivalent of, say, Google Glass and submitted a MobiSys paper on it, it would have been rejected as "not novel enough" since <a href="http://hci.stanford.edu/courses/cs547/Resources/Pictures/thad_starner.jpg">Thad Starner has been wearing a computer on his head for 20 years</a>. And high-altitude Internet balloons? What's new about that? It's just a different form of WiFi, essentially. Nothing new there.</div>
<div style="text-align: left;">
<br /></div>
<div style="text-align: left;">
We still need to publish research, though, which is important for driving innovation. But we should shift to an open, online publication model -- like <a href="http://arxiv.org/">arXiv</a> -- where everything is "accepted" and papers are reviewed and scored informally after the fact. Work can get published much more rapidly and good work won't be stuck in the endless resubmission cycle. Scientists can stop wasting so much time and energy on program committees and conference organization. (We should still have one big conference every year so people still get to meet and drink and bounce ideas around.) This model is also much more amenable to publications from industry, who currently have little incentive to run the conference submission gauntlet, unless publishing papers is part of their job description. And academics can still use citation counts or "paper ratings" as the measure by which hiring and promotion decisions are made.</div>
</div>
Unknownnoreply@blogger.com37