Dropbox Selective Sync Bug, or How It Took a Whole Evening to Update My Profile Photo

I encountered a pretty bad Dropbox bug today. I'm wondering if anybody else has encountered anything similar, and also wanted to share how I got around it in case it happens to anybody else.

This evening I was changing my Twitter profile photo back to the usual photo, as one is wont to due on a Sunday evening while procrastinating work. I was horrified to discover that the photo was nowhere to be found. In fact, my entire "photos" folder containing all of my key photos of the last few years was gone. It was not in my machine's Dropbox folder, not in any of my machines' Dropbox folders, and not on the Dropbox website.

I was not entirely surprised. Over the last few months I've been having some problems maintaining a shared Dropbox folder between my Linux and Windows partitions. I think the main problem is that Dropbox for Linux is simply not very good, but the fact that my use case is so fringe probably doesn't help. My trajectory of use has gone something like this: set things up according to some blog post; enjoy file sharing across partitions for some time; start getting strange error messages about starting Dropbox on Linux; sit helplessly and watch as something strange happens. Previously, the "something strange" involved Dropbox failing to work anymore. This time, involved my files failing to exist anymore.

Bug: selective sync doesn't uphold its end of the bargain. This latest episode of something strange happening had to do with my using the "selective sync" feature. This feature supposedly allows users to select which folders each machine syncs with Dropbox, allowing users to store terabytes of data on Dropbox (because that's what we're paying for) without needing to eat up terabytes of data on each machine. When you choose to selectively sync, an icon appears assuring you that the files are disappearing only from your machine, and not from all of Dropbox. Except, in my case, the files disappeared from all of Dropbox. I assume what happened was that the selective sync had registered as a deletion, but not a proper deletion, or otherwise it would have made it easier for me to retrieve the files.

Fix: do sketchy things to get at files. After sending Tech Support a strongly worded note about how-could-they-lose-all-my-files, I started poking around the Dropbox website. I discovered a "Deleted Files" section that allows you to restore files you deleted up to a month ago. Restoring here recovered many of the missing files, but not all of them. (After all, I had lost the files through a bug, and not in some normal way of deleting files.) I then went to the "Events" page and confirmed that there had been an event October 2, after syncing my Linux partition, that involved the deletion of over 1000 files. (Thanks, Dropbox, for not sending me a message asking if I was sure this was something I wanted to do.) Still no sign of the "photos" folder and the desired new/old profile photo. All I needed was a link to the folder. Once I had that, I could request to restore the files.

After this, I was almost out of ideas when I realized that some of my Dropbox "shared" folders had been subfolders under the "photos" folder, and that the Dropbox website has a separate section for managing "shared" folders. (When other people share folders with you, you can choose whether to actively add the folders to your Dropbox. I had un-added most of my folders before I upgraded to more space.) So I went there and and restored these folders. Then I looked in the "Recents" tab and there it was, a link to the "photos" folder, corresponding to a notification that subfolders had been re-added to my Dropbox. Now that I had a link to the "photos" folder, I was able to click on the "show deleted files" icon. Once I was able to see the deleted files, I was able to restore them. (And I've been doing them one subfolder at a time, while writing this post, because there are bugs when I try to do multiples at a time...)

And this, ladies, gentlemen, and people who identify as neither ladies nor gentlemen, is the story of how I changed back my Twitter profile photo.

Conclusions. All software has bugs, so I can't be particularly angry with Dropbox, but there are many ways in which Dropbox can improve user experience with respect to this particular situation. Here are my main takeaways:

• Until Dropbox pays more attention to their Linux product, one should be wary of selective sync. (Dropbox! We're paying so much money for this! The least you could do is to not put us through these emotional roller coasters by deleting our files after promising not to.)
• If you're not getting what you want out of a user interface, it may be possible to do sketchy things until you can get where you want to go. But Dropbox could also improve its interface for accessing files that may have been disappeared against the will of the users.
• There are tradeoffs to using something like Dropbox instead of managing your file backup yourself. On the one hand, you give up control and are subject to their bugs wiping out your entire digital photo archive. On the other hand, respectable companies do keep a lot of backups and with some work you should be able to recover things. So, thanks Dropbox for not deleting these files altogether, even though you really didn't make it easy for me to find them.

And, of course, this brings us to my main points in life. We need to understand our software better! Better languages and tools would allow programmers to better understand what is going on, making these kinds of strange bugs less likely! Allowing programmers to express high-level policies about consistency and desired system behavior would also decrease the prevalence of these kinds of situations! Instead of funding Dropbox, maybe people should fund programming languages research kthxbai!

On Avoiding Stress Culture

I've been at Carnegie Mellon University as an Assistant Professor for a little over a month now, and the students tell me we're approaching "Deep Semester." The glow of summer vacation has worn off. People are skipping classes and skipping meals in pursuit of Excellence. A pall of Seriousness has descended upon the Gates Hillman Complex. (Many days this week, the Seriousness has physically manifested as heavy rain.)

Now is a good time to remind myself that I can stay out of it*. Jim Morris, the former Dean of CMU's School of Computer Science, once told me, "Stress culture is worst among junior faculty. Avoid it." Jim seems to live by this advice. He teaches a course called Campus Stress as a Wicked Problem**. My friend Chinmay, who is in the Human-Computer Interaction Institute with him, tells me Jim is one of the few professors on campus who isn't "so busy" all the time.

At first glance, it may seem difficult to avoid stress culture as a junior faculty member. After all, everyone knows that being junior faculty means working all the time, never sleeping, and having so little of a life outside of work that you can only keep plants alive if they are in the office. But people also seem to think being a PhD student means working all the time, and there are many examples of successful people who did not work all the time as PhD students. Thus I'd like to posit the hypothesis that the idea that one must work "all the time" as junior faculty comes more from a culture of stress than necessity for success.

But why, you might wonder, would this stress culture exist among junior faculty members if it were unnecessary? I speculate below:

• Your responsibilities are much more divided than they were before and it's difficult to juggle. It's possible to spend all time doing any of the following: teaching, advising, writing grant proposals, and attending committee meetings. Also note that this list does not include the reason you presumably became faculty in the first place: doing research. The solution is not to implode, but to compromise.
• The closer you get to the top of a hierarchy, the more intense people get. When I go out into the real world people find me to be a total megalomaniac. My academic peers don't seem to think the same thing about me.
• A lot of people who made it all the way to becoming faculty did get there by working all the time. Though not the only way, this is a legitimate way of working.
• As humans we're not engineered to say "no" too often, and there are infinite things to say no to as a faculty member. If I said yes to every meeting and answered every email I'd die of not eating and not sleeping very quickly. (This might be a harder thing for women because we're socialized to be agreeable.)

In support of my hypothesis that stress culture is something to be eschewed rather than embraced, I present a list of my role models when it comes to finding space and balance:

• My undergraduate professor Radhika Nagpal. This recent excellent profile of her talks about how, as junior faculty, she avoided politics and made it a rule not to check email on weekends. She wrote the most-read post on Scientific American's website about her approach to the tenure track called "The Awesomest 7-year Postdoc."
• Turing Award winning MIT professor Barbara Liskov, who famously worked only 9 to 5 on weekdays, working an evening here and there only if there was a deadline.
• The aforementioned Jim Morris, and also my friend Chinmay, who seem to make time to do the things they want to do.
• My postdoc advisor Walter Fontana, who lives by the Goethe quote "Do not hurry; do not rest." He seems to have always found the space to do the science he wants to do. He once told me it is important to have a "strong internal compass" and know when you believe your work to be good so you can avoid pressures to hire more and publish more.

Stress culture might not be bad for everyone***, but it certainly is not productive for me. (My friend Seth once observed that I seem to work best in the complete absence of pressure.) So though I could be doing more work, right now I'm going to go read a book. Good night.

* In Influence, Robert Cialdini says if you want to do something, tell the entire world. Then you'll feel more accountable and be more likely to do it.
** The course focuses on problems at CMU, but in terms of pressure CMU is not so different from the other elite higher-education institutions I've experienced.
*** A student once told me I needed to put more pressure on him so he would get more work done!

Some of My Niceness Role Models

Yesterday my friend Grzegorz asked me if I knew how to prevent promising students from becoming "brilliant jerks," and I opened up this question to the Internet because I didn't know. One theme in the responses is to set a good example, demonstrate that you value niceness, and make visible examples of people who are both brilliant and nice. This made me realize that niceness is high on my list of qualities I appreciate in people, and that I keep in mind a growing list of "niceness role models" who remind me to be not-a-jerk in different ways. Here is a subset of those people.

• Margo Seltzer, my undergraduate academic advisor at Harvard. Despite being so busy, famous, important, etc., Margo always made time for us. She took meetings with me whenever I asked, responded to my long angsty emails with similarly long emails of advice, and took me to lunch every now and then to make sure I was doing all right. When our robotics team was in the RoboCup World Cup in Germany, she came to Germany to cheer us on (though it probably didn't hurt that the real World Cup was there at the same time) and even brought me German gummy bears, because she knew of my love for candy and bears. And this was not because I was particularly special--other students I've talked to are in awe of how much time and space she makes for us. My friend Diana once said that if Margo is not too busy and important for us, then who are we to ever think we are too busy or important for anybody else.
• Armando Solar-Lezama, my PhD advisor at MIT. As a PhD student I was something like a research cat, always bringing in random ideas and visitors I had "hunted" into Armando's office to see how he might engage with them. Throughout my PhD Armando was incredibly generous with his time and attention, always engaging with whatever--or whomever--I brought, and never telling me that I had wasted his time, or to stop. Whenever I'm inclined not to listen to an idea or person, I think of how patiently Armando listened to us--and with genuine curiosity.
• Martin Rinard, my other thesis committee member at MIT. Martin has a reputation in our field for being loud, controversial, and not necessarily the warmest person on the planet, but he also has a reputation among the PhD students for being an incredibly supportive advisor and mentor. Martin goes above and beyond to train students in creative ways. He once made one of his international students practice his speaking skills by "re-lecturing" every one of his morning lectures in the evening for the class he was teaching one semester. Throughout my PhD, Martin felt I needed to learn to fight better, so he put me in situations of needing to defend myself whenever possible (most publicly throughout my entire thesis defense). Whenever I'm inclined not to care about other people's growth, I think about how generous Martin was with his time and advice.
• Max Krohn, who co-founded Spark Notes, OKCupid, and Keybase. Max did his undergrad at Harvard and his PhD at MIT and is now worth so much money that when I hosted him to speak at MIT I had to meet several times with the handler MIT assigned him because they had identified as a potentially high-impact donor. While many people of Max's profile are too important to be nice to anybody, Max is incredibly nice, and also generous with his time and attention. I had first met Max when my friend (and co-founder of a company that never ended up existing) reached out to Max for advice, and Max has continued to impress me with how unassuming he is, how much he listens, and how much he genuinely tries to be helpful. My interactions with Max reinforce the lesson that I should not ever view myself as too successful to be nice, and to pay it forward when it comes to supporting younger people.
• My friend Alison Hill. Alison is a brilliant and very successful HIV researcher who, at a fairly early point in her career, received a prestigious Gates Foundation grant to run her own lab. How I've always known her, though, is as the friend I could always count on to say "yes" to fun things, and to be there to talk if I needed it. Most recently, Alison spent over 30 hours designing, choreographing, and organizing the rehearsals for a dance-skit for our friend Adeeti's wedding. Whenever I think I am too busy for my friends (which happens all the time), I think about what Alison would do.
• Dominic Mazzoni, someone I worked with when I interned at Google in 2007. He was not my mentor, but I interacted with him quite a bit because I used the (very useful and well-engineered) machine learning tools he was developing. I was so impressed with how nice he was in all of his emails and code reviews: he would thank the sender for the correspondence, be complimentary about legitimately good things, and convey what seemed like genuine joy about the interaction. I especially appreciated that he took my questions seriously, even though I was some random intern--and not even his intern. Interacting with Dominic reminded me of how nice it can be when someone tries to make interactions pleasant, and whenever I remember to do so (which is not often enough), I try to be more like him.
• Einstein. Every time I feel like I am too busy to engage in correspondence to a stranger, I think about Einstein's letter to a young girl interested in science, and how if Einstein wasn't too busy and important changing the world to respond to people, then I shouldn't be either.

I feel grateful that I know so many people who are simultaneously so brilliant and so nice! (And there are so many more nice, brilliant people in my life!) Obviously I would die if I tried to be as nice all of these people combined (and most of the time I forget to try to be nice at all), but it's very useful to have people like these in mind to remind myself to be nicer. And I think that for all communities I'm in, it would improve overall morale to give more credit for niceness and not just brilliance.

Question: "Correcting brilliant students"

A question for all of you.

--

from:		Grzegorz Kossakowski
to:		Jean
date:		Fri, Sep 23, 2016 at 10:51 AM
subject:		Correcting brilliant students

Hi Jean,

I know from your tweets you're busy so I'll get right to the point. I'm looking for examples of academic teachers who try to edify brilliant freshmen students in hope to steer them away from the unfortunate path of a brilliant jerk. Based on your blog posts, I thought you might be the right person to ask and you would find the subject interesting.

I'm asking about this in context of a recent conversation with the head of algorithms and datastructure research at University of Warsaw. He's called here in Poland as father of our ongoing successes in ACM competitions. He have heard that University of Warsaw has a reputation of graduating people who are really good but not pleasant to work with and he's looking for ideas to correct that. I promised to try to help hence my email.

--

gkk

--

from:		Jean Yang
to:		Grzegorz Kossakowski
date:		Fri, Sep 23, 2016 at 10:54 AM
subject:		Re: Correcting brilliant students

Haha, you mean you can tell from my Tweets that I've been procrastinating work? ;)

This is a very good question. Hm! Could I turn this email into a blog post and solicit suggestions from people? This is indeed an interesting question to me and I don't know the answer.

Jean

Five Things More Important About a Research Project Than Being in Love

I recently talked to an early PhD student trying to decide between two projects: one they were in love with, and one with a much longer list of "pros" including "more likely to go somewhere" and "the faculty involved have experience working in the area." I was surprised to learn that I was the only person (out of faculty and students alike!) who told her I would pick the second, more reliable project.

It's not that I'm not a romantic*, but I do believe advice to make decisions based on feelings rather than facts can be dangerous. Apparently my point of view is so much in the minority that I need to write a blog post to elucidate my position.

Like most of you, I am a sucker for stories about people finding meaning, love, etc. When I watched movies as a kid, I would always be so confused when the female lead turned down a proposal from a perfectly eligible paramour**. But they look so good together! But they are in love! As time passed, however, I learned that there is this thing called happiness, that happiness is important, and that happiness depends on many more factors than looking good and being in love.

And as I came to learn that all things in life are the same, I learned that these lessons also apply to research. For me, the following things are as important, if not more important, than the specific dream I am chasing in any given research project:

1. The day-to-day. I'd love to be a lab scientist for the glamorous photographs of me in my lab (and of course the direct contributions to science, etc.), but I am pretty sure I would die if I had to spend my days doing wet lab experiments. (In high school my "will become" in my senior yearbook was "a better lab partner." This unfortunately never happened. In college I loved studying organic chemistry but I would do things like accidentally shatter our sep funnel and throw it away, leaving my lab partner confused about why we were missing half our experiment.) What I love doing is coding, formalizing things every now and then, and apparently, spending days and days writing grant proposals and Powerpoint presentations. Hence my present set of projects.
2. Collaborators. For some reason people love this idea of the lone scholar. (Maybe because it's hard enough to imagine one person who wants to work on such obscure stuff??) In reality, most science (and probably all other things in life) moves forward not only through single people sitting alone in their attics, but through conversations between people sitting in attics. It's good to know whether you like working by yourself, with a small handful of collaborators, or on massive collaborations where you can't ever tell how many other people are on the same Skype call. There are tradeoffs to each of these situations: the fewer people you collaborate with, the more "out there" your work can be. The more people you collaborate with, the bigger the project can be (for different senses of "big"). Especially when you are working hard, your collaborator interactions are most of your entire world, so it is important to like both the collaboration format and the collaborators.
3. Community. People tell you that the PhD is about the relationship between a student and their advisor, but it's really about the student entering into a set of conversations within a community. My happiness certainly depends on my position within a community: how much the community accepts me/my work; how much my community values my work and similar work. I like being part of a research community that shares my values; I like it when my community accepts me as one of them and engages with me about my work. As a young researcher, your community is especially important because these are the people who will shape your values and your ideas about what it means to do research.
4. Evaluation. I used to think that once work was good enough, it would be universally recognized as good, and then we could all celebrate and move on. Unfortunately, this is not the case, and each community has its own customs about how it evaluates work. The evaluation mechanisms determine what work gets recognized as good and ultimately how people work. I much prefer my work to be evaluated on things that feel more objective than subjective, and I want to believe the evaluation is demonstrating something about a universal truth, rather than being a measurement of a particular artifact. (For these reasons, I prefer to be evaluated on correctness--in the form of theorems--than user studies or performance numbers.) This determines what I choose to work on and what I emphasize when communicating about my results, decisions that play a large role in my work-happiness.
5. Resources. Behind all things in life there is the question of money. While most people would certainly not like their work to be completed dictated by what funding is available, how much funding there is and where it comes from determines many things about your work: whether you have funding to travel to conferences; whether you have additional funding meetings where you are to present concrete deliverables. There are also other resources besides the financial. How many people at your university could give you feedback on this project? How many other people could contribute to actual work on the project? For young researchers, there is also the question of how much attention the advisor would provide on a project, and also the attention other researchers in the field might provide.

Of course, everyone has their own happiness function. I'm sure many other people value the idea of being in love with their research more, and value some of these less. No matter what your value function, it is important to think about the dimensions of your happiness, and how project decisions fit.

Supplementary reading:

• Cal Newport's "The Passion Trap: How the Search for Your Life's Work is Making Your Working Life Miserable."
• "How common is it for PhD students to do work they are not passionate in?," on Quora with an answer by me.
• "In the Name of Love," a Jacobin article critiquing the "do what you love" mantra from a different perspective.

* Hm, people have called me the "least romantic person they have ever met."
** Hey, it's not my fault the movies I watched conformed to heteronormative tropes.

A Small Reading List for New PhD Students

It's my first semester being on the other side! Giving advice is so fun because it validates all of my life choices! I put together a list of reading for my own students and thought others might find it useful too.

• You and Your Research, a talk by Turing Award winning mathematician Richard Hamming with so much good advice: work hard; don't be afraid to work on small problems; learn to tolerate ambiguity.
• The Passion Trap: How the Search for Your Life's Work is Making Your Working Life Miserable by Georgetown Computer Science professor Cal Newport, on how you should expect to do work and then fall in love with it, rather than the other way around.
• David Allen on How to Fix Your Life by a journalist at The Atlantic, on setting up your life so you can focus.
• What Else Should Grad Students Be Learning? by Harvard Computer Science professor Michael Mitzenmacher, on important non-technical skills PhD students should learn.
• On Productivity in Grad School by me. It's harder to summarize your own writing.

I would also like to reiterate advice from my undergraduate professor Radhika Nagpal that it's important to take all advice with a grain of salt, as  most of it is wishful thinking and highlights. I would like to add that taking productivity advice from other people is about as useful as taking diet advice from fashion magazines. Everyone has different goals and everyone is working with different biology and a different environment. The concept of "productivity" seems to also be subject to various strange fads.

Even so, I would love to hear your recommendations.

Yet Another Blog Post on Industry vs. Academia

I recently had the following chat conversation with a Former Student about the possibility of doing a PhD in Computer Science*.

FS: What's the value of grad school if I don't want to stay in academia (other than "grad school might be fun")?
FS: There, I *think* that's the question I've been trying to ask
Me: Oh
Me: Enrichment
Me: You learn to think differently when you go so deep into one thing
Me: You also learn to execute
Me: It's very challenging to do a project start to finish
Me: Maybe I'll write a blog post for you
FS: That's a good reason, but it isn't something I haven't gotten in industry
FS: In fact actually I thought that one advantage of grad school would be that id get to do a more diverse set of things
FS: Than I do now

So here is the blog post in which I expand on my point and explain what I see as some skills one may develop more while doing a PhD** than working at a company. (I have this other "academia is fun" post about the PhD.)

Commitment. A defining characteristic of a good PhD thesis is that it solves a problem of sufficient scale and initial uncertainty ("a big enough research problem"). This usually involves commitment in at least two dimensions, time and emotion. Especially in non-theory areas of Computer Science, problems worth solving can take years before yielding satisfactory results. This kind of timeline seems quite different from what I've seen in industry. Committing to a research problem also means committing to uncertainty and faith that you will one day find a solution. This often involves believing in ideas that many other people don't believe in--in fact, Great Work is often met with initial disapproval. Learning how to become robust to other's lack of approval is useful for most of life. (And not something companies necessarily train you to do. In fact, it's in their best interest to train you for the opposite.)

Execution on open-ended problems. The point of having a company is to build a product that makes money. A product is more likely to make money if it actually works. Thus, in companies, a lot of the focus seems to be on getting the details right on things we already know we can build. The more time I've spent at a company, the better of an engineer I've become, and the better at Engineering Process. In research groups, much of the focus is on collecting evidence that you could build things you previously weren't sure could really exist. While engineering is certainly a useful skill here, more important skills include prototyping ability, and the ability to deal with significant uncertainty during the research process. (This is perhaps why research code so often does not meet engineers' standards.)

Self-direction. For many, the PhD involves long stretches of time working on one's own. (In the very least, the dissertation is a document that you are expected to write on your own.) Most advisors will not micromanage this time, especially in the later stages of a PhD. As a result, sooner or later PhD students will need to manage the relationship between work and time day-to-day and also month-to-month and even year-to-year. Though my industry internships have all been pretty self-directed, in which I was given a project and told to make as much progress as possible, I've been told this is not usually the case in companies. Self-direction makes you a more independent employee if you want to return to industry. On the one hand, people may feel comfortable giving you more responsibility. On the other hand, you may have trouble working for other people after getting used to working for yourself.

Emotional resilience. There are three parts of most (many? my?) PhD experience(s) that do not seem to be part of most industry experiences: 1) solitary work, 2) long periods of thinking without doing, and 3) long periods of doing without having much to show for it. This leads to many existential crises, as the emotionally difficult nature of the process causes one to Question Everything. I'd like to think that people emerge stronger from these existential crises. One of my college roommates has been getting a PhD in Comparative Literature and during our PhDs we often discussed how our research situations forced us to deal with questions about our values and goals, and how we felt that this process of questioning led to important emotional growth. The existential crises that a PhD exposes you to seem more similar to the experience of starting a company than that of being employed by one.

And on diversity of topics: in graduate school you will get breadth from classes, you will get to see a breadth of work in your field through reading papers, attending talks, and talking to other researchers, but depending on how your PhD is structured you may work on very few different projects. The Computer Science PhD provides a certain kind of intellectual breadth, rather than breadth of work.

I'd like to add that the "graduate school vs. industry" debate is like the "public school vs. private school" debate, or other debates that make no sense in a vacuum. Yes, in principle there are many ideological differences, but there are very applied research groups and very experimental industry groups. In practice, it really depends on the specific circumstances. Even so, one way to look at a PhD is as an investment into having greater access to experimental groups. There may be industry groups now that let you do out-there things, but without a PhD you rely on certain companies continuing to exist.

Anyway, as much as I would like said Former Student to do a PhD (and specifically with me :)) it really depends on FS's particular situation, hopes, and dreams. And since everyone's situation is different, I'm also curious to hear what others think they "get" out of a PhD (other than "fun," and the opportunity to continue on the academic track).

* I wrote this post with programming languages/systems research in mind. I'm curious how well it generalizes.
** What I say definitely applies for students in top CS PhD programs with advisors who give them certain kinds of freedom. I'm not sure how it applies to everyone else.

Ten Recipes for the Beginner Cook

This blog post is dedicated to my college roommate Brigit, who has been ramping up her cooking efforts.

This week I've been on vacation with my college roommates and we've been having many conversations about how we've come a long way since learning how to boil water--for some of us, a skill acquired post-college. Being someone who likes food but is lazy about cooking, I've developed a repertoire of easy recipes over the years. Here are ten of them.

1. Massaged kale salad. Salads are kind of a loophole to adulthood: as long as you spend the time and money on good ingredients, all you have to do to "cook" a salad is wash some things and maybe chop some things. Massaging kale makes it feel a little less like cheating. (And kale is much better massaged.)
2. Arugula walnut salad. This salad is even less effort. Putting random fruit and random nuts into a salad always makes the salad better, both in terms of nutrition and how fancy it looks. Some weeks when I am really busy I just stock my kitchen with greens, fruit, and nuts. Sprouts (especially flavorful ones) are a nice touch, as well as thinly sliced radish.
3. Baked salmon. Good salmon (or any kind of fish, really) can be quite inexpensive and be really easy to make. (My college roommate Aliza says salmon is expensive in New York, but in Cambridge I usually spent $5-7 on half a pound of quite good salmon at my local Whole Foods.) Once you learn how to do it you can do variations on the different marinades to make it feel like a different dish every time.
4. Skillet-roasted spiced okra. I love okra, but for a long time I did not realize how easy it is to cook for yourself. The recipe I linked to includes lots of spices (and is similar to bhindi masala), but okra can be quite good with only cumin and turmeric, or even only with salt.
5. Quinoa tabouleh. This is a really delicious and nutritious prepare-your-own lunch food. For a while I quit quinoa due to ethical concerns and used couscous instead, but these concerns turned out to be unfounded.
6. Pasta puttanesca. This is a nice emergency hunger recipe because you can make it completely out of backup ingredients that last forever in your kitchen. One time I made pasta puttanesca completely out of found ingredients in the London apartment of my college roommate Marianne's uncle, to which I had been given a key and was instructed to wait for Marianne's post-midnight arrival.
7. Shakshuka. This is a great brunch recipe that seems to impress people. It is one of those recipes that has a lot of ingredients (and there are many variations you can find online), but once you have the ingredients it's not very much work.
8. Lentil soup. This one takes a little more time, but none of the steps are difficult and you can make a batch that lasts a really long time and you can freeze parts of it.
9. Chinese sticky rice cake. Every time I've made this, people have been amazed by both how delicious it is and how easy it was to make. You pretty much just put the ingredients together and stir. I substitute almond or soy milk and the recipe is still fine.
10. Noodles. Those who have spent extended time with me know that they are an important staple of the Jean Yang diet. I wrote this blog post about cooking with noodles in 2009. My college roommate Aliza wrote this essay about how I got her into noodles.

Would be curious to hear yours. Enjoy!

A Starter Reading List About Asian America

Race in America isn't something I talk a lot about online, but it is something I think a lot about. Today I was giving my friend Seth a short reading list about being Asian American when I realized that 1) I have such a list and 2) other people might like to see it too.

Here are some essays I like:

• Wesley Yang's "Paper Tigers" in NY Mag about the "bamboo ceiling" and the culture clash between American and Asian-American values when it comes to achievement.
• David Byunghyun Lee's "Transformed Into White Gods: What Happens in American Without Love," a beautiful and moving essay about the frustration, hopelessness, and hope of his immigrant experience.
• Jenny Zhang's "Far Away From Me" in Rookie Mag about the stereotypes people project onto Asian women.
• Tracy Chou's "The uncomfortable state of being Asian in tech" on Medium about how we need to start talking about what it means to be Asian in tech.
• Alton Wang's "When I Grow Up I Can't Be President" on Medium, about the Chinese-American experience.
• Chenxing Han's "We're Not Who You Think We Are" on Lion's Roar about the marginalization of Asian-American Buddhists. (Chenxing also happens to be the first friend I made after moving to America.)

For a much longer read, I really liked Helen Zia's book, Asian American Dreams, about the formation of Asian American identity. (Tea that Burns is another good one about Chinese-American history. Fun fact: I wrote my high school junior history essay about the Chinatown that used to be in Pittsburgh. Yes, there was one until the city government put a highway through it.)

Apparently our friend Nate Hilger, an economics professor at Brown, is doing research on discrimination against Asian-Americans. He has a working paper, "Upward Mobility and Discriminations: the Case of Asian-Americans," here.

Of course, I've also been really enjoying the proliferation of TV shows featuring Asian-American immigrant family experiences: Fresh Off the Boat, Master of None, and The Mindy Project among them.

Would love to hear your suggested reading/watching.

Counter-Advice for the PhD

Recently I attended the Programming Languages Mentoring Workshop, a program to introduce advanced undergraduates and early-stage PhD students to research in general and research in our field. (By the way, this is a fantastic workshop and I highly encourage students to attend!) While listening to advice from other academics and talking to the students about their questions, I realized that I have come to disagree with much of the conventional wisdom and advice for PhD students, some of which I have been guilty of re-dispensing. I express my dissent here.

Clarification: The workshop was not the source of all of the quotes! It was simply what got me thinking about the dangers of taking any one piece of advice too seriously. (The workshop itself is great for showcasing different points of view.)

--

"To decide what to work on, read lots of papers and then choose the best problem."
One of my undergraduate professors once told me, "Take all advice with a grain of salt. Most advice is highlights and wishful thinking." This was one of the best pieces of advice anyone has ever given me. It is easy for people to give this kind of advice about choosing research problems after they have learned what makes a good research problem. The advice is far more difficult to follow for people who are still developing their research taste. While some people probably have chosen research problems this way and while it is helpful to more deeply understand your area, early-stage researchers sometimes just have to jump in, do things, and learn from the confusion.

Also, in the early stages of a PhD, developing research skills (project management, time management, and communication of results) can be far more important than working on the best problem. In this case, I would recommend working on a problem that a mentor is sufficiently invested in to help you gain the skills you need.

--

"Choose an advisor you are completely compatible with."
This advice goes in the same category as the previous one. Once you have gone through the PhD and developed a deep understanding of who you are and who your advisor is, it is easy to think that a good situation can be easily recreated or a bad situation could have been more easily avoided. While you should look enough into your soul and do enough due diligence to make sure there are no glaring red flags, you should not worry if you do not feel like you know enough about your working style or preferences to choose a perfectly compatible advisor. Advisor-advisee relationships, like all other human relationships, depend a lot on many factors, only some of which are under the control of the two main participants, and also can evolve quite a bit over time.

--

"Do a PhD because you are in love."
 I completely agree that doing a PhD out of love of learning, love of discovery, or love for a discipline is a much better reason than doing a PhD for the money, fame, or glory. But I've seen many students get stuck in the "passion trap," the idea that you need to be completely in love with something before you invest significant amounts of time and energy into it. According to Cal Newport, who has written extensively about this, passion is something that often comes later, after you have become an expert and people recognize you for your contributions.

What I have noticed is that people often differ more in the narratives they have about their relationships with their work than in their actual relationships with their work. In my Quora answer to the question "How common is it for PhD students to do work they are not passionate in?" I talk about how one's relationship with a project often follows a trajectory similar to a romantic relationship: infatuation, followed by a steady state that comes sometime later, often much later, with a period of confusion and negotiation in between. I've seen every researcher I know well experience the confusion phase, but some researchers are more open than others to talking about it.

A side observation is that relationships with research seem to vary culturally: for instance, being blanket positive about one's own research seems to go along with the American tendency to be blanket positive about one's own life.

--

"Superstars are born, not made."
No one has said this specific phrase to me, but many people have implied it with the qualities they value in students. Once a professor told me that some students "just can't cut it." I've seen professors pick favorites based on internal metrics they have (often, it seems, based on how much a student reminds them of themselves). I've seen students decide someone is the smartest among them because of confidence, or some other "star" quality that doesn't necessarily correlate directly with research skill. While there is a baseline level of intelligence, curiosity, drive, and tolerance for uncertainty that someone needs to be a good researcher, many of the qualities that make a great researcher--discipline and persistence, to name two--are not entirely innate and definitely not strongly correlated with the confidence and charisma that seem to build many star reputations. (Note: confidence and charisma can also be learned.)

--

"The PhD is lonely without a significant other, especially if you are a woman in a male-dominated field."
I was surprised that people have told me this--and that, at least when I was starting my PhD, there was a common conception that having a romantic partner was somehow necessary for enduring the trials of the PhD. While it is important to nurture healthy relationships with supportive people, a significant other does not need to be one of them. Especially in relationships between people of similar levels of ambition, it can become tricky to negotiate coevolution and colocation, thus adding unnecessary pressure to the PhD experience. (And, unfortunately, because of society's insistence on holding on to gender roles, women who date men often find themselves with more pressure to conform to their partner's desires.) During my PhD, I had many friends, some of them women in male-dominated fields, many who ended up becoming stars in their fields, who were happily single for significant portions of their PhD.

--

"The most successful PhD students work all the time."
See my answer (and other answers) to the Quora question "Do Ph.D. students have time for hobbies?" Nurturing a relationship with a significant other also counts as a hobby, so you can do that too if that's what you want.

--

"If it's not hard, it's not worth doing."
There is something to be said for only doing things that help you grow in some way, but there is necessary challenge and then there is unnecessary challenge. During the PhD, it is necessary to come to terms with uncertainty, confusion, and possible rejection of your ideas from the community. This is crucial for one's development into a full-fledged researcher. What is less necessary, however, is depriving yourself of food or sleep, always working to the point of exhaustion, or mismanaging your time so that you are always under deadline pressure. For some people it may be necessary to endure toxic advisor or collaborator relationships, but I would encourage those people to seek ways out of that if possible--abuse does not need to go hand-in-hand with growth. Self-inflicted struggle only makes the necessary struggle more difficult.

--

I hope you realize by now that there is no single right way to do the PhD and that there are many valid--and sometimes conflicting--views on what a good path is. Have fun with the confusion. :)

"We run things, things don't run we"

Yesterday was Porchfest, an annual event where local musicians perform on their porches all around Somerville, MA. My friend Stefan Anderson, who performs as the solo act The Stefan Banderson, played his cover of Miley Cyrus's "We Can't Stop," which is my favorite cover of all time. (Summer 2013 I heard him perform the cover before I heard the actual song.)

Something I like about Stefan's covers is how they highlight the absurdity of pop song lyrics. During this performance I became obsessed with the line "We run things, things don't run we." After I spent far longer thinking about this line than a serious adult should, I had the following enlightening email exchange with the friends I went to Porchfest with.

This is another post in the series where I experiment with publishing emails the way RMO does. This post is about not being able to stop. It is also about what happens when science PhDs close-read Miley lyrics.

(While we're on the topic of Porchfest I'd also like to plug my friend Christiana's band Paper Waves. Check them out--they're great!)

--

from: Jean Yang to: Alison Hill, Elizabeth Brown, Ali Rabi date: Sun, May 22, 2016 at 10:46 AM subject: We run things, things don't run we
Guys I looked this up and this is a real lyric of the song. I really like it. I think I'll make it my new life motto.
---

from:		Elizabeth Brown
to:		Jean Yang
cc:		Alison Hill, Ali Rabi
date:		Sun, May 22, 2016 at 11:05 AM
subject:		Re: We run things, things don't run we

Oh my god that is wonderful. It makes a great motto!

--

from:		Alison Hill
to:		Elizabeth Brown
cc:		Jean Yang, Ali Rabi
date:		Sun, May 22, 2016 at 12:55 PM

Ahh but it's more subtle that that .. see the full stanza below:

And we can’t stop
And we won’t stop
We run things, things don’t run we
Don’t take nothing from nobody

the final "we" of the third line also serves as the subject of the fourth line .. optionally .. or you could interpret the lines separately, and then the last one is not a statement but an imperative

but all this just makes me like it even more!

--

from:		Jean Yang
to:		Alison Hill
cc:		Elizabeth Brown, Ali Rabi
date:		Sun, May 22, 2016 at 3:18 PM

Yeah, one can also interpret as a fight to control the forces that control us.

I read this article about how "We Can't Stop" is actually a sad song:
http://www.businessinsider.com/why-miley-cyrus-we-cant-stop-is-actually-the-saddest-song-of-the-summer-2013-8

This particular stanza is particularly interesting as a commentary on the power you give up when you enter into a super glam life--whether it's partying or academia. You act like you run the show but you've already bought in to something much bigger and you "can't stop." "Don't take nothing from nobody" and maybe you can escape the greater forces.

SO MUCH SUBTLETLY I LOVE IT.

A Recent Exchange on Money and Time

Below is a recent exchange with my friend Rob Ochshorn, who often writes emails instead of blog posts to work out his thoughts. Here I am borrowing not only his technique, but also his thoughts, on a topic I have recently begun to think about and would like to think about more.

Seth and Aliza were included non-consensually. I continue to include them for context: this conversation happened with an audience.

---

from:		Jean Yang
to:		Aliza Aufrichtig, Robert M Ochshorn, Seth Stephens-Davidowitz
date:		Sun, May 15, 2016 at 10:57 AM
subject:		Cultural shorthand for money and time

Our society has a widely used abstraction for things that cost money ($$$) but there's not similar concept for time.

I started thinking about this because I wanted a way to express things that are time-expensive (was thinking ).

Related to this, it would be nice if people could tell me how much time things cost, rather than just how much money. Thinking about this made me wonder how much our lack of shorthand for this idea is a result of our entire society not caring about time as much as money, or because the people who shape our cultural shorthand (for instance the people running Yelp) care more about money than time.

Zooming out even further, isn't it interesting that Silicon Valley has become so obsessed with helping people live forever--while perpetuating a culture that steals people's time and youth in an unprecedented all-consuming way? (Based on how you think about it, it is or isn't unprecedented. Let's discuss.) I wonder what this means...

---

from:		Robert Ochshorn
to:		Jean Yang
cc:		Aliza Aufrichtig, Seth Stephens-Davidowitz
date:		Mon, May 16, 2016 at 2:33 AM
subject:		Re: Cultural shorthand for money and time

If only the singularity-upload fantasy of an eternal life were based on a mature understanding of leisure! I’m using “leisure” to mean the non-financialized use of time. This distinguishes it from the manner of time that Silicon Valley loves to “save” you. I mean, most of these stupid startups justify their work in terms of saving you time. Some startups allow you to convert your money into somebody else’s time (InstaCart, TaskRabbit, Magic), while others use automation and interface, in the grand tradition of the dishwasher, to let you do your work/chores faster (“so you can focus on …”). 

I would dispute your claim that our society cares about money more than time. I think it’s worse than that: much tech marketing and ideology[0] is based on the myth of a temporal-financial relativity: the conversion of money into time (the inverse, time->money, being what we call a job).

Your Yelp example is interesting. It makes me think of the 50s fantasy of “fast food.” Silicon Valley has proposed a modernization of this concept (Soylent), which should make clear what the purpose of this time-saving is: that we will have more time to work! In other words: what is the point of “saving time” if not to prepare or enjoy a nice meal?

Iconographically, there’s some design precedent creeping into popular consciousness. Medium, for example, numerically estimates the time an article will take its average user to ingest (“5 min read”). I’m kicking myself for not introducing you to my friend Tristan, who just passed through Cambridge for a Berkman lecture and runs a Time Well Spent movement that sees itself as a time-respecting “Fair Trade” equivalent for tech. What I like about your “” is that it implies a depth and prestige to a potential long-form experience—it makes me feel like I will be taken out of my normal, fragmentary, hectic existence and transported into a deep, coherent, and focused place for a while. The watches culturally suggest wealth and tradition. It’s a very different feel with hourglasses ()—perhaps the difference between being in control of one’s time verses our lives slipping away from us.

There’s a media-theoretical concept that’s important here: Marshall McLuhan’s notion of the reversal. The automobile makes us faster, but when you extend the concept as far as it goes, we’re stuck sitting in traffic. Ivan Illich took this even further, making a brutal calculation[1] of a car’s speed based on all of the factors that allow us to occasionally sit in a car cruising down the open road.

So for precedent I would propose McDonald’s, the dishwasher, and the automobile. Think about the ways they play together: teenagers working at McDonald’s to buy a car while their mothers enter the workforce, aided at home by the dishwasher.

Warm greetings from Ramallah! Time definitely seems to work differently here.

Your correspondent,

R.M.O.

[0] This is slightly off-topic, but it’s too lovely to omit. From Levy’s Inside the Googleplex, a great snapshot how time and latency are discussed/traded within Google (emph mine):

After the Code Yellow, Google set a companywide OKR (the objective key result metric Google uses to set goals) to fight latency. To help meet its goals, the company created a market-based incentive program for product teams to juice up performance—a cap-and-trade model in which teams were mandated latency ceilings or maximum performance times. If a team didn’t make its benchmarks, says Hölzle, it accrued a debt that had to be paid off by barter with a team that exceeded its benchmarks. “You could trade for an engineer or machines. Whatever,” he says. The metric for this exchange was, oddly enough, human lives. The calculation goes like this: average human life expectancy is seventy years. That’s about two billion seconds. If a product has 100 million users and unnecessarily wastes four seconds of a user’s time every day, that was more than a hundred people killed in a year. So if the Gmail team wasn’t meeting its goals, it might go to the Picasa team and ask for ten lives to lift its speed budget into the black. In exchange, the Gmailers might yield a thousand servers from its allocation or all its massage tickets for the next month.

[1] From Wikipedia:

…the concept of counterproductivity: when institutions of modern industrial society impede their purported aims. For example, Ivan Illich calculated that, in America in the 1970s, if you add the time spent to work to earn the money to buy a car, the time spent in the car (including traffic jam), the time spent in the health care industry because of a car crash, the time spent in the oil industry to fuel cars ...etc., and you divide the number of kilometres traveled per year by that, you obtain the following calculation: 10000 km per year per person divided by 1600 hours per year per American equals 6 km per hour. So the real speed of a car would be about 3.7 miles per hour.

Networking Tips for Younger PhD Students

This post was a collaboration with Nadia Polikarpova and Shachar Itzhaky, done while we were supposed to be collaborating on other things.

A younger student in the group where I did my PhD is going to his first conference next week and my advisor sent him my way for advice. Nadia, Shachar, and I had already been discussing research (and attending a BBQ) for hours at this point, so we welcomed the opportunity to discuss something else. Here's what we came up with.

• Be prepared to show off your research. A main goal of attending a conference is to get your name out there, associated with good work. At a conference, you'll be lucky to get more than five minutes in with someone, especially somebody established. It would serve you well to prepare a succinct, memorable elevator pitch for your work. If you have a demo, it doesn't hurt to have that ready in case someone wants to see. Bonus: if you can tailor your pitch based on the interests of who you're talking to, they'll like it more.
• Make your networking bingo sheet--and play it. Make a list of people who you'd like to talk to: people about whose work you have questions, people whose work you cite/whose papers your read, people you'd like to tell about your work, and people whose work you admire in general. You may want to consult your advisor and/or collaborators for a good list. Having a list helps keep you on track for making the most of your time at the conference. I also like feeling like I'm on a mission.
• Don't be afraid to ask for introductions. While most people in my community (programming languages) are pretty friendly, it can often be easier to talk to someone if you get introduced. Don't be afraid to ask people if they are able to introduce you to someone on your bingo sheet.
• Don't sit with the same people twice. This is a conference, not vacation with your best friends. My former advisor Saman Amarasinghe liked to tell his PhD students to split up at all meals so they can meet new people. It's fine to have a friend you go around the conference with, but make sure you're talking to new people during each break and meal.
• Prepare questions and talking points. When I was a first-year PhD student attending my first POPL, my friend Luke and I were so excited to see Xavier Leroy, one of our research heroes, standing by himself during the break that we ran up to him and introduced ourselves. As we had no further game plan, we answered the questions he asked us about who we were and then we ran away. At the next conference, PLDI, I was determined to do better. I asked his student, Jean-Baptiste, if I could have lunch with them on one of the days. I figured that since Jean-Baptiste was my friend, Xavier could become my friend by transitivity. The conference flew by and we ran out of lunches, but Jean-Baptiste said I was welcome to walk with them while Xavier fetched his suitcase and walked to get a cab. Again, I was very excited, but again, I had nothing to say and the conversation more or less consisted of me answering questions that Xavier politely asked me. Ever since, I've always made sure to prepare a couple of questions and/or talking points if I really want to talk to someone. It also doesn't hurt to prepare a couple of general stories/talking points to break the ice when you sit at that lunch table full of people you don't know.
• Listen more than you talk. It is well known that Level 1 networking for graduate students involves ambushing innocent passers-by with a well-rehearsed elevator pitch. While this more or less does the job, there are greater heights to aspire to. The next level involves listening to and interacting with the other person. In How to Win Friends and Influence People, Dale Carnegie talks about how much more people like you if you let them talk first and figure out what they want to talk about. This is also true in research settings. I, for one, tend to be much more impressed with someone if they can ask insightful questions/offer useful suggestions about my work than if they simply presented to me interesting ideas about their own work.
• Dress appropriately. Dressing appropriately increases one's efficacy in all situations and conferences are no different. Your main fashion goals at a conference are 1) not to stand out too much, 2) to be sufficiently mobile to move between groups and between the conference venue and evening activities, and 3) to be sufficiently comfortable that you can last from the morning until late at night. For 2), make sure your backpack isn't too big and you don't have too much stuff but have your jacket/comfortable shoes if you're going to head out with a group for dinner and/or drinks.
• Carry a notebook. If you're doing it right, you'll be having lots of conversations. It will be useful to write down things you learn and things to follow up on. Notebooks are also useful for drawing figures to describe your research.
• Always wear your nametag. People are going to remember who you are a lot better if they see your name every time they look at you.
• Mind your manners. You want people to remember you for your research without being distracted by poor manners. It's a good idea to be careful not to interrupt people and not to make a mess when you eat. I also try not to make too big of a deal out of my dietary restrictions when we're making decisions about where to eat. It makes it a lot easier, especially in large groups, if you try to be agreeable and go with the flow.

Finally, have fun. Conferences have helped me solidify friendships with many people in my research area. Especially as you spend more time in a community, conferences can become more like a family reunion than a serious networking event with faceless paper authors.

As always, let us know if you have other tips!

Why It's Not Academia's Job to Produce Code That Ships

Note: The images in this post are inexplicably broken due to some kind of Blogger bug. If someone is reading this at Google, please help!

My scientist friends often scoff at crime show writers' creative interpretation of technology's limits.

The technology shiny world of CSI: Cyber.

"Let's zoom in here," a character says in an investigation room with floor-to-ceiling screens showing high-definition maps of the show's major metropolitan area. A flick of the fingers reveals an image of the suspect at mouth-watering resolution.

In another scene, the characters listen to a voice mail from the suspect. "What's that in the background?" one investigator asks. Using an interface that deadmau5 would kill to have, the hacker of the bunch strips out the the talking, the other sounds. They say some words like "triangulation" and, eureka, they deduce the suspect's exact location.

Yes, real police technology is nowhere near this sophisticated. Yes, nobody (except maybe the government, secretly) has technology like this. But those who criticize the lack of realism are missing the point.

The realities that art constructs take us out of our existing frames of perception--not only for fun, but also for profit. Many important technological advances, from the submarine from the cell phone, appeared in fiction well before they appeared in real life. Correlation does not imply causation, but many dare say that fiction inspires science.

Some complaints against academic Computer Science.

This brings us to the relationship between academic Computer Science and the tech industry. Recently, people in industry have made similar criticisms of academic computer science. Mike Hoye of Mozilla started the conversation by saying he was "extremely angry" with academics for making it difficult for industry to access the research results. This unleashed a stream of Internet frustration against academics about everything from lack of Open Access (not our faults) to squandering government funding (not entirely true) to not caring about reproducibility or sharing our code (addressed in an earlier blog post).

At the heart of the frustration is a legitimate accusation*: that academics care more about producing papers than about producing anything immediately (or close to immediately) useful for the real world. I have been hearing some variation of this criticism, from academics as well as industry people, for longer than I have been doing research. But these criticisms are equivalent to saying that TV writers care more about making a good show than being technically realistic. While both are correct observations, they should not be complaints. The real problem here is not that academics don't care about relevance or that industry does not care about principles, but that there is a mismatch in expectations.

It makes sense that people expect academic research results to work in companies right away. Research that makes tangible, measurable contributions is often what ends up being most popular with funding sources (including industry), media outlets, and other academics reviewing papers, faculty applications, and promotion cases. As a result, academic researchers are increasingly under pressure to do research that can be described as "realistic" and "practical," to explicitly make connections between academic work and the real, practical work that goes on in industry.

In reality, most research--and much of the research worth doing--is far from being immediately practical. For very applied research, the connections are natural and the claims of practicality may be a summer internship or startup away from being true. Everything else is a career bet. Academics bet years, sometimes the entirety, of their careers on visions of what the world will be like in five, ten, twenty years. Many, many academics spend many years doing what others consider "irrelevant," "crazy," or "impossible" so that the ideas are ready by the time the time the other factors--physical hardware, society--are in place.

The paths to becoming billion-dollar industries.

In Computer Science, it is especially easy to forget that longer-term research is important when we can already do so much with existing ideas. But even if we look at what ends up making  money, evidence shows that career bets are responsible for much of the technology we have today. The book Innovation in Information Technology talks about how ideas in computer science turned into billion-dollar ideas. A graphic from the book (on right) shows that the Internet started as a university project in the sixties. Another graphic shows there were similarly long tech transfer trajectories for ideas such as relational databases, the World Wide Web, speech recognition, and broadband in the last mile.

The story of slow transfer is true across Computer Science. People often ask me why I do research in programming languages if most of the mainstream programming languages were created by regular programmers. It we look closely, however, most of the features in mainstream languages came out of decades of research. Yes, Guido Van Rossum was a programmer and not a researcher before he became the Benevolent Dictator of Python. But Python's contribution is not in innovating in terms of any particular paradigm, but in combining well features like object orientation (Smalltalk, 1972, and Clu, 1975), anonymous lambda functions (the lambda calculus, 1937), and garbage collection (1959) with an interactive feel (1960s). As programming languages researchers, we're looking at what's next: how to address problems now that people without formal training are programming, now that we have all these security and privacy concerns. In a media interview about my Jeeves language for automatically enforcing security and privacy policies, I explained the purpose of creating research languages as follows: "We’re taking a crazy idea, showing that it can work at all, and then fleshing it out so that it can work in the real world."

Some may believe that all of the deep, difficult work has already been done in Computer Science--and now we should simply capitalize on the efforts of researchers past. History has shown that progress has always gone beyond people's imaginations. Henry Leavitt Ellsworth, the first Commissioner of the US Patent Office, is known to have made fun of the notion that progress is ending, saying, "The advancement of the arts, from year to year, taxes our credulity and seems to presage the arrival of that period when human improvement must end." And common sense tell us otherwise. All of our data is becoming digitized and we have no clue how to make sure we're not leaking too much information. We're using software to design drugs and diagnose illness without really understanding what the software is doing. To say we have finished making progress is to be satisfied with an unsatisfying status quo.

The challenge, then, is not to get academics to be more relevant, but to preserve the separate roles of industry and academia while promoting transfer of ideas. As academics, we can do better in communicating the expectations of academic research (an outreach problem) and developing more concrete standards of expectations for "practical" research (something that Artifact Evaluation Committees have been doing, but that could benefit from more input from industry). As a society, we also need to work towards having more patience with the pace of research--and with scientists taking career bets that don't pay off. Part of the onus is on scientists for better communicating the actual implications of the work. But everyone else also has a responsibility to understand that if we're in the business of developing tools for an unpredictable future--as academics are--it is unreasonable to expect that we can fill in all the details right away, or that we're always right.

It is exciting that we live in a time when it is possible to see technical ideas go from abstract formulations to billion-dollar industries in the course of a single lifetime. It is clear we need to rethink how academia and industry should coexist under these new circumstances. Asking academics to conform to the standards of industry, however, is like asking TV writers to conform to the standards of scientists--unnecessary and stifling to creativity. I invite you to think with me about how we can do better.

With thanks to Rob Miller and Emery Berger for helping with references.

* Note that this post does not address @mhoye's main complaint about reproducibility, for which the response is that, at least in Programming Languages and Software Engineering, we recognize this can be a problem (though not as big of a problem as some may think) and have been working on it through the formation of Artifact Evaluation Committees. This post addresses the more general "what are academics even doing?!" frustration that arose from the thread.

--

Addendum: Many have pointed out that @mhoye was mainly asking for researchers to share their code. I address the specific accusation about academics not sharing code in a previous blog post. I should add that I'm all for sharing of usable code, when that's relevant to the work. In fact, I'm co-chairing the POPL 2017 Artifact Evaluation Committee for this reason. I'm also all for bridging the gaps between academia and industry. This is why I started the Cybersecurity Factory accelerator for turning commercializing security research.

What I'm responding to in this post is the deeper underlying sentiment responsible for the misperception that academics do not share their code, the sentiment that academics are not relevant. This relevance, translating roughly into "something that can be turned into a commercial idea" or "something that can be implemented in a production platform" is what I mean by "shipping code." For those who wonder if people really expect this, the answer is yes. I've been asked everything from "why work on something if it's not usable in industry in the next five years?" to "why work on something if you're not solving the problems industry has right now?"

What I'd like is for people to recognize that in order for us to take bets on the future, not all research is going to seem relevant right away--and some if might never be relevant. It's a sad state of affairs when would-be Nobel laureatees end up driving car dealership shuttles because they failed to demonstrate immediate relevance. Supporting basic science in computer science involves patience with research.

Dual Booting Windows 10 and Ubuntu 16.04

For a couple of years, secure boot was making it harder every time to install a Windows/Linux dual boot. I've just finished successfully setting up a dual boot on my Lenovo X1 Carbon and am happy to report that it requires more or less the same tedious steps as before.

Here are step-by-step instructions for setting up a dual boot, where Windows has already been installed.

1. Shrink the size of your Windows partition. Create a partition for Linux, an optional swap partition for Linux, and an optional other partition if you want to share files between your two partitions. You don't need to format your Linux and swap partitions. You will want to format the optional shared partition as NTFS.
2. Get an Ubuntu image onto a DVD or a USB drive.
3. Turn off Fast Boot in Windows. If you don't do this, your system is going to boot straight into Windows every time.
4. In your BIOS, disable Secure Boot, enable UEFI, and disable Legacy Boot. You can mess with your BIOS settings by restarting and then intercepting startup by pressing "enter."
5. Boot from your image. You can do this by restarting and intercepting startup to boot from a device. When choosing the installation option, make sure to choose "something else" instead of the ones that erase all your files.
6. Follow the instructions and install Linux onto the partition(s) you've set aside for it. You will need to select the intended Linux partition and format it as ext[something] (I did ext3) and set the mount point as the top directory. You'll also need to designate the swap partition as such. You'll also have to explicitly specify your boot partition. Since you already have Windows installed, this will be the first partition formatted fat32. (This was different than before. I don't recall ever having to explicitly reformat my Linux partition or choose my boot partition.)
7. From Linux, run Boot-Repair to reinstall your GRUB. Otherwise you'll boot straight into Windows every time. (If you accidentally booted back into Windows, you can repair your GRUB by running Linux live off your boot device.)
8. If you want to share files between Windows and Linux, you'll also need to configure your shared partition so you can use it in Linux. (Instructions here. I had to restart before Dropbox let me put my directory there.)

Enjoy!

P.S. Does anyone know when I'd ever want to use Legacy Boot? According to everything I've read it doesn't seem like I ever need it for anything. Why is it there?