Saturday, June 19, 2010

Cocktails for Computer Scientists

One of the keys to success in academia is being able to make a good cocktail. Many a night I have slogged through a grant proposal or stack of recommendation letters for students with a Sazerac or Martinez in hand. One might think that regular imbibement of cocktails and the demands of faculty life are not exactly compatible, though I disagree. Moderation is important, of course; but not nearly as important as the requirement to stop working once you've finished off your third drink. It is a nice timeout mechanism.

Most of my friends know little about cocktails, or their idea of a cocktail is a boring old vodka martini or a margarita. (On the other hand, Michael Mitzenmacher is a fan of the Long Island Iced Tea, which essentially involves dumping whatever booze you have laying around into a glass.) Any time we have friends over I am in instant bartender mode and pushing new drink discoveries on them. So, I give to you, Matt's Guide to Classic Cocktails for Computer Scientists, or how to become a cocktail geek in four easy steps.

Step One: Use good ingredients. High-quality ingredients make all the difference in cocktail making, just as in cooking and any other endeavor. It was an absolute revelation the first time I tasted a proper añejo tequila -- sweet, smooth, not at all like that harsh stuff that you use to do shots. Those bottles of Jack Daniels and Bacardi you have left over from your college days? Chuck 'em. Stock up on a good, proper bar. At minimum, you'll need a nice bourbon or rye (Black Maple Hill or Hudson Valley); gin (Junipero or Plymouth); rum (Zaya or Ron Zacapa 23 Años); and sweet vermouth (Carpano Antica or Dolin). Vodka is totally unnecessary and best left for "fauxtinis". Other important ingredients for making real old-school cocktails include absinthe, maraschino liqueur, brandy, and the occasional exotic boondoggle like Batavia Arrack or Creme de Violette. If you are just getting started I recommend holding off on these extras until you need them.

Bitters are one of the most important components to a bar. My favorite, by far, are The Bitter Truth Jerry Thomas' Own Decanter Bitters. You should always have a bottle of Angostura on hand, and Peychaud's as well. Orange bitters are used in many classic drinks. Bitterman's Xocolatl Mole Bitters make a great conversation piece. I have six or seven kinds of bitters at my bar and my theory is you can never have too many.

Make yourself a batch of simple syrup: two parts sugar to one part water, boil in the microwave, put into a glass bottle in the fridge. You'll use it all the time. Spike it with a stick of cinnamon or a handful of whole black peppercorns and you can produce a masterpiece. Fresh lemons and limes should always be on hand. I tend to eschew olives and those gross nuclear-fallout colored "maraschino cherries."

Step Two: Get a decent cocktail book. Most of these are utter garbage. The worst are those that simply list a zillion cocktails in alphabetical order by name and don't tell you anything about the ingredients, history, or variations on the drink. The best classic cocktail book is Imbibe! by David Wondrich, which is a modern interpretation of Jerry Thomas' original cocktail guide from 1862 . (Reprints of the latter can now be found on Amazon!) Wondrich's writing is superb; the book is heavy on lore. If you want to make cocktails the proper, 19th century way, this is a good place to start. Online, CocktailDB is fairly comprehensive and makes it easy to search for recipes, but I find this approach overwhelming. Better are cocktail blogs such as Cocktail Virgin and spiritsandcocktails.com (among many others), which are more focused.

Step Three: Make some drinks. Now that you have your ingredients and your handy guidebook, what to make? I recommend starting with the very basics and go for an Old Fashioned: muddle bitters with a sugar cube and a little bit of water; add a couple of ounces pour of good bourbon or rye; stir with ice. That's it. This is not the Old Fashioned you will get at a typical bar (which loads the drink with a fruit salad).

Variations: Improved Rye (or Bourbon) cocktail: same as above, but add a dash of absinthe and maraschino liqueur, stir with ice and strain. A Manhattan made with proper bourbon and Camparo Antica vermouth is to die for. Substitute Fernet-Branca for the vermouth (and add a dash of simple syrup) and you have a Toronto Cocktail, probably my favorite drink these days. Flame an orange or lemon peel over the drink and you are gettin' really fancy.

A good gin martini -- with dry vermouth and orange bitters -- is an excellent thing. Use sweet vermouth instead (again, Camparo Antica) and sub Old Tom Gin instead of dry gin and you get a Martinez, the precursor to the martini, very 1880's. That one needs a lemon peel rubbed on the rim of the glass for full effect.

If you want to show off, make a Trinidad Sour -- a full ounce (!!) of Angostura bitters, orgeat (or sub simple syrup), lemon juice, a bit of rye. I guarantee you're not going to find that at Applebee's. This is for advanced cocktail drinkers only.

Step Four: Research. You can never go wrong by leaving it to the pros. In Boston, the best places for classic and modern craft cocktail making are Drink, Eastern Standard Kitchen, Green Street Grill, Craigie on Main, and Deep Ellum. Don't just order a drink that you already know -- talk to the bartender, get to know them, learn about the craft, get their recommendation. Drink encourages this by not having a cocktail menu; they expect customers to discuss what they like and don't like with the bartender. Usually when I go there I just tell them to make me something good, and they do.

Off to make up another Jamaican Ginger Cocktail #3...

Thursday, June 17, 2010

Working for The Google

I am about to take a one-year sabbatical from Harvard to join Google. If you haven't heard of them, Google is this little startup company with this really neat website that lets you search for just about anything on the Internet. It is very cool.

I'm going to be at the Google office here in Cambridge (since I can't move my family right now) but expect to work with folks at the Seattle and Mountain View offices. This way I can also keep tabs on my research group at Harvard and hopefully keep things moving along here. But largely I am going to be stepping back from my academic responsibilities -- I intend to fully dive into the Google job and immerse myself in that environment.

A lot of people have asked me what I'll be doing at Google. I can't say much, but I will hint that it has to do with using high-energy lasers to digitize real objects into a computer system called the MCP. I am sure nothing can possibly go wrong with this project.

Seriously, I only have a vague idea of what I will be working on, but the high order bit is that my job title is simply "software engineer." Essentially, I'll be writing code. Not leading a project or doing "research" or anything like that. To be honest, this makes me extremely happy -- I miss hacking on a daily basis and look forward to being a grunt in the trenches, so to speak. As far as I can tell, this is how most people come into Google, regardless of their level of experience. Craig Chambers, who left a tenured position at University of Washington to join Google, told me that he came in as a software engineer, hacking on someone else's project, and it wasn't until he had been at it for a while that he started defining his own projects and leading his own teams.

The way I think of it, being in academia is a lot like building toy boats and playing with them in your bathtub.

From http://www.flickr.com/photos/timothymorgan/522553650/
Of course, this has many advantages -- you get to completely define the experimental environment, don't need to worry about aspects of the boat design that don't interest you, and can explore radically new designs without much concern for legacy approaches or "making money." At the same time it can get pretty disconnected from reality, depending on how you approach it.

Whereas being at Google is like working on an aircraft carrier at sea.

From http://www.naval-technology.com/projects/cvn-21/cvn-211.html

In my case, my job will be to polish the portholes on the poop deck, and I won't have much influence on the overall design or direction of the ship -- but hey, I'll learn a lot in the process. There is also something very attractive about writing code that will actually be part of a running system and potentially used by millions of people every day. Of course, I'll have to get used to things like writing tests and doing code reviews, and working under a vast number of constraints that we tend to ignore in academic settings.

Keep in mind I've never really worked as a software engineer. In a lot of ways I feel totally unqualified to teach my students about writing good code or building reliable systems since I've never actually had to do it myself. (That's not quite true -- the research systems I build are subjected to rigorous stress testing, but certainly aren't mission-critical the way Google's code has to be.) A stint at Google will hopefully make me a better programmer, system designer, and researcher.

I'm not yet sure whether Google is going to let me continue blogging while I'm there -- hopefully they will let me blog about non-Google-related topics, but we'll see. Maybe I just need a pseudonym -- if you see a blog pop up called "Final and Centralized" you'll know it's me...

Monday, June 14, 2010

Editor in Chief

In a bout of temporary insanity, I've agreed to serve as Editor-in-Chief of ACM Transactions on Sensor Networks, which is probably the top journal in the field. Feng Zhao, the Assistant Managing Director of Microsoft Research Asia, has been the EIC since the journal's inception some six (?) years ago, and has done a fantastic job building up the journal and putting together a fantastic editorial board. I've been on the editorial board for a while and overall the quality of the submissions is pretty high. It's an honor to be selected for this role and I hope to keep up the great work that Feng has started.

Systems people tend to eschew journals in favor of conference publications, but I still think that TOSN has an important role to play in the sensor nets community. We need a place to publish longer, more thorough papers than what you can typically cram into a 14-page conference submission. We need a place for papers of high quality that just won't make it into a decent conference -- retrospectives, position papers, surveys, and so forth.

Of course, a major problem with journal submissions (and TOSN in particular) is the very long review cycle. It's just not acceptable for papers to take a year (or more!) to get reviews back. Having served as an associate editor I know how hard it is to corral reviews from good people and get things done in a timely fashion. Of course, some AE's are better at cracking the whip than others. We also need more regular turnover of the editorial board membership to avoid burnout.

Coming into the job, I have three main ideas for how to improve TOSN's standing in the community. Of course I'm open to any and all suggestions beyond these:


1. Improving the connection between TOSN and sensor network conferences. I think it's important that we formalize a process whereby the best papers from SenSys, IPSN, and other venues are fast-tracked to TOSN. We should be more proactive about this and give authors a chance to use TOSN as a venue for publishing a "journalized" version of a good conference paper. This has been done informally for a while but I plan to make the process much more overt.

2. Encouraging submissions of survey papers, article versions of PhD dissertations, and retrospectives. We need more outreach to the community to make it clear that we want these kinds of submissions. Again, this is mainly about being more proactive about soliciting these papers and getting the word out.

3. Introducing special issues. Feng made the decision to avoid special issues in the early life of the journal, for the good reason that it was important to establish TOSN before branching out to specialized topics. Now that TOSN is well established, I think the time is right to have 1 or 2 special issues a year, especially on topics that may be difficult to publish in a conventional manner. One example would be a special issue on industry experiences with sensor networks. If you have suggestions for special issues (or better yet, would like to serve as editor for one!) please let me know.

Wednesday, June 9, 2010

Margo Seltzer is blogging

My colleague Prof. Margo Seltzer has started blogging at http://mis-misinformation.blogspot.com/. She is joining the ranks of such distinguished Harvard Computer Science faculty who maintain blogs, including Michael Mitzenmacher, Harry Lewis, and Stuart Shieber. (Apparently, we have nothing better to do than stuff the interwebs with our crazed ramblings.)

Margo, welcome to the blogosphere. It's a lot like real life, only weirder.

Sunday, June 6, 2010

How to get tenure at Harvard

There is an old joke that says that at most universities, you have to write a book to get tenure, while at Harvard, they have to write a book about you. I am not sure who wrote that one, since I recently found out that I've been promoted to full professor with tenure. (Unlike most places, at Harvard, full professor is the only tenured rank. I've actually been an associate professor for three years now and the total clock is seven years.) So my time as a disgruntled junior faculty member is drawing to a close - on to the far more entertaining life as a (presumably) gruntled senior faculty member.

Harvard has a notorious reputation for not tenuring its own junior faculty. Indeed, some departments have not promoted from within for decades -- so long that they probably don't remember how to do it if they wanted to. In the math department, for example, junior faculty treat the job like an extended postdoc, with the goal of getting tenure somewhere else -- Yale or Columbia perhaps. You'd have to win the Fields Medal to get tenure in math at Harvard. Such departments treat the end of a junior faculty member's contract as an opportunity to scout out the best person in the world to fill the position, and typically the best person is 20 years more senior and at another school.

This is the classic Harvard model, but in recent years Harvard has started to use the term "tenure track" for the first time in its history. Since I joined Harvard in 2003, we have tenured six CS faculty from within, and turned down tenure to two people. The CS faculty here (and, more generally, the entire School of Engineering and Applied Sciences) are extremely supportive of junior faculty and we work hard to ensure that everyone has the best shot at tenure.

Unfortunately, this attitude is not pervasive, and often rubs against the antiquated culture found elsewhere in the university. For example, it was only recently that Harvard's request for tenure letters explicitly stated that candidate X from Harvard was actually under consideration for the job. The letters still request explicit comparisons against a set list of other faculty who are typically expected to be *full professors* at other schools, and respondents are asked to rank the candidates. To be promoted you need to be ranked first or second consistently across the letters. It is a very daunting process for a junior faculty member.

At many universities, tenure decisions are made at the department or school level, with the university essentially rubber-stamping those decisions. Not so here. The final step of the Harvard tenure process is the mysterious and fearsome ad hoc committee meeting, which is presided over by the President of the university, who has the final say. For this meeting, three senior faculty from other universities come and grill the internal "witnesses" that may support or oppose the case. I am pretty sure the meeting also involves a ritual with a human skull and a goblet of blood, but cannot confirm as of yet.

Now that I've passed the trial by fire, there is one last step. Harvard does not tenure anyone without a Harvard degree, and I've never been here as a student. So next fall, they will grant me an honorary Master's degree to clear that burden. I am not making this up.

From then on I hear it is just smooth sailing, lazy days with few responsibilities and just raking in the paychecks and use of the private parking space. Right? Right?

I'd like to thank all of the people who really made this happen. More than anything else, my tenure is a reflection on the hard work and vision of my amazing students and postdocs -- who took my wild-eyed whiteboard ramblings and turned them into reality. More often than not, though, the best ideas came from the students themselves. I have learned so much from them and have been extremely fortunate to have such an amazing group. I'd especially like to thank Margo Seltzer and Greg Morrisett for their tremendous effort in marshaling my case through the process. Thanks to Michael Mitzenmacher for the puff piece on his blog today. Finally, great thanks to all of my faculty colleagues for their encouragement and willingness to put up with my crap in our weekly lunch meetings.

(Once I've had a chance to digest it, I'll post a more personalized account of what it took to navigate Harvard's tenure process.)

Startup Life: Three Months In

I've posted a story to Medium on what it's been like to work at a startup, after years at Google. Check it out here.