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...

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...

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.

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.

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.)

The Secret Lives of Professors

I came to Harvard 7 years ago with a fairly romantic notion of what it meant to be a professor -- I imagined unstructured days spent mentoring students over long cups of coffee, strolling through the verdant campus, writing code, pondering the infinite. I never really considered doing anything else. At Berkeley, the reigning belief was that the best and brightest students went on to be professors, and the rest went to industry -- and I wanted to be one of those elite. Now that I have students that harbor their own rosy dreams of academic life, I thought it would be useful to reflect on what being a professor is really like. It is certainly not for everybody. It remains to be seen if it is even for me.

To be sure, there are some great things about this job. To first approximation you are your own boss, and even when it comes to teaching you typically have a tremendous amount of freedom. It has often been said that being a prof is like running your own startup -- you have to hire the staff (the students), raise the money (grant proposals), and of course come up with the big ideas and execute on them. But you also have to do a lot of marketing (writing papers and giving talks), and sit on a gazillion stupid committees that eat up your time. This post is mostly for grad students who think they want to be profs one day. A few surprises and lessons from my time in the job...

Show me the money. The biggest surprise is how much time I have to spend getting funding for my research. Although it varies a lot, I guess that I spent about 40% of my time chasing after funding, either directly (writing grant proposals) or indirectly (visiting companies, giving talks, building relationships). It is a huge investment of time that does not always contribute directly to your research agenda -- just something you have to do to keep the wheels turning. To do systems research you need a lot of funding -- at my peak I've had 8 Ph.D. students, 2 postdocs, and a small army of undergrads all working in my group. Here at Harvard, I don't have any colleagues working directly in my area, so I haven't been able to spread the fundraising load around very much. (Though huge props to Rob and Gu for getting us that $10M for RoboBees!) These days, funding rates are abysmal: less than 10% for some NSF programs, and the decision on a proposal is often arbitrary. And personally, I stink at writing proposals. I've had around 25 NSF proposals declined and only about 6 funded. My batting average for papers is much, much better. So, I can't let any potential source of funding slip past me.

Must... work... harder. Another lesson is that a prof's job is never done. It's hard to ever call it a day and enjoy your "free time," since you can always be working on another paper, another proposal, sitting on another program committee, whatever. For years I would leave the office in the evening and sit down at my laptop to keep working as soon as I got home. I've heard a lot of advice on setting limits, but the biggest predictor of success as a junior faculty member is how much of your life you are willing to sacrifice. I have never worked harder than I have in the last 7 years. The sad thing is that so much of the work is for naught -- I can't count how many hours I've sunk into meetings with companies that led nowhere, or writing proposals that never got funded. The idea that you get tenure and sit back and relax is not quite accurate -- most of the tenured faculty I know here work even harder than I do, and they spend more of their time on stuff that has little to do with research.

Your time is not your own. Most of my days are spent in an endless string of meetings. I find almost no time to do any hacking anymore, which is sad considering this is why I became a computer scientist. When I do have some free time in my office it is often spent catching up on email, paper reviews, random paperwork that piles up when you're not looking. I have to delegate all the fun and interesting problems to my students. They don't know how good they have it!

Students are the coin of the realm. David Patterson once said this and I now know it to be true. The main reason to be an academic is not to crank out papers or to raise a ton of money but to train the next generation. I love working with students and this is absolutely the best part of my job. Getting in front of a classroom of 80 students and explaining how virtual memory works never ceases to be thrilling. I have tried to mentor my grad students, though in reality I have learned more from them than they will ever learn from me. My favorite thing is getting undergrads involved in research, which is how I got started on this path as a sophomore at Cornell, when Dan Huttenlocher took a chance on this long-haired crazy kid who skipped his class a lot. So I try to give back.

Of course, my approach to being a prof is probably not typical. I know faculty who spend a lot more time in the lab and a lot less time doing management than I do. So there are lots of ways to approach the job -- but it certainly was not what I expected when I came out of grad school.

Update 4/24/10: Thanks to Mike Belfrage for pointing me to this interview with Niklaus Wirth where he echoes some of the above sentiments.

Proposal: Improving the NSF Review Process

Summary: Let's improve the NSF proposal review process by making it function more like conference program committees.

Intellectual merit: The core problem that this proposal addresses is the poor quality of many reviews submitted by NSF panelists. It is not uncommon for a proposal to be rejected with short, content-free reviews, offering little feedback to the authors. In many cases the scoring of a proposal is poorly justified, leaving the author mystified as to why they got such a low (or high) score. Recently, I had a proposal rejected where one of the reviews was essentially a single sentence in length. Not only does this not help the PI improve the work for later submission, but it leaves the impression that the review process is arbitrary.

(I'd like to emphasize that this is a problem that many NSF program managers have called attention to, but they are powerless as individuals to do much about it. So I believe the fault rests with the research community, not with the NSF PMs.)

A key problem with NSF panels is that there is no community standard for what constitutes a good (or even acceptable) proposal review. I am a strong advocate of the approach used by the systems community, where paper submissions are given extremely detailed reviews with constructive feedback. Given that we spend so much effort reviewing papers, couldn't we also give the same effort to NSF proposals, which arguably are more important than a single paper?

It is my impression that NSF program managers also have a hard time pulling panels together, mainly because people are so busy, and don't have the time to travel to DC. Yet many of the potential panelists freely serve on conference program committees with much higher reviewing loads and an expectation of much more detailed reviews. (A typical panelist will review 8-12 proposals, whereas a competitive conference will require TPC members to review 2-3x as many papers.) Why? One reason, perhaps, is that program committees are recognized for their work, and serving on a TPC is an important indication of one's stature in the research community.

These two issues are related. Since serving on an NSF panel is seen as "paying your dues," rather than an activity you take pride in, there is little incentive to write good reviews. However, if you write a bunch of crappy reviews for a TPC, you can earn a reputation as someone who doesn't take the process seriously might not get invited back in the future. So the public recognition of the TPC and the quality of the reviews go hand in hand.

My proposal: Let's have NSF panels emulate the conference program committee model. First, we should recognize panelists publicly for their work. Being on the "NSF NeTS 2010" panel should be as prestigious as serving on SIGCOMM or SenSys. The NSF should create a web page for each years' competition where they list the panelists and list the proposals funded through that competition (the latter information is available, but a little hard to dig up). So the community can take pride in the effort and see the outcome of the process more directly.

Second, establish expectations for high-quality proposal reviews. If you are a bad panelist, you won't get invited back in the future, so you won't gain the recognition of being asked to serve. Panelists will be chosen from among the best people in the field, where "best" is defined both by research contribution and service.

Third, hold panels somewhere other than Washington DC. Since I live in Boston, it's easy for me to get down there, but for people on the West Coast it is much harder. If panels are run in different locations around the country, the travel burden can be spread around more evenly.

I will be the first to admit that the conference program committee model is not perfect -- see my related posts here and here for thoughts on that. But in my experience it is better than the (typical) NSF panel.

Of course, NSF's conflict-of-interest guidelines will have to be tweaked. Currently, you can't serve on an NSF panel for a program for which you have submitted a proposal. (The upshot is that panels tend to consist of people who didn't get their act together to submit a proposal, which may not be the best group of scholars to evaluate the work.) Recently NSF has separated larger programs into multiple panels and simply ensured that someone can't serve on the specific panel for which their own proposal is under consideration.

Broader impacts: Improving the proposal review process and providing more constructive feedback to PIs will result in better science.

In the comments, please indicate your rating for this proposal:
   Excellent
   Very Good
   Good
   Fair
   Poor