The Problem with "Mansplaining"

The "mansplaining" meme, which captures the phenomenon of men being patronizing to women in conversation, is trending on the internet. There is a Tumblr here; a Hillary Clinton meme there. While it is good that women are speaking out about sexism, there are some issues with using the term "mansplaining." Not only does it distract from the real problems, it also perpetuates behaviors that prevent progress. Allow me to mansplain.

The term "mansplaining" conflates two issues: that men tend to explain things in a manner that may be interpreted as patronizing and that people explain things to women with the assumption that they are ignorant. The first can largely be explained by conversational differences between men and women: in Talking from 9 to 5, Georgetown sociolinguist Deborah Tannen discusses how in conversations, (American) men tend to seek a dominant position, while women tend to prevent the other person from taking a subordinate position. Men also often use knowledge (for instance, statistics about sports teams) to establish this dominance. It is no wonder, then, that conversations between men and women often end up having the man explaining things in a condescending manner to women. Rather than mocking men, it is more productive to create awareness of these conversational differences. Men can use this awareness to be more careful when talking to women (or anyone else from a culture where establishing dominance is not the norm) and women can use this awareness to perceive the situation differently (for instance, be less offended or intimidated) when talking to men.

Because it brings in stereotypes about men vs. women, the "mansplaining" distracts from the real issue: that people are often condescending to women. In Why So Slow?, psychologist Virginia Valian explains that this often because of statistical bias. Using heuristics to make snap judgments is how we are able to effectively deal with overwhelming amounts of input. Using these same heuristics is often why people (men and women) assume women are less capable. Especially in technical fields, there are fewer capable women. Thus, given any specific woman, she is more likely to be ignorant than knowledgeable. Thus a reasonable snap judgment is to assume that a woman knows less than she does. Fortunately, we can second-guess our snap judgments. Awareness can again mitigate this problem: if we know we are likely to make a snap judgment that is wrong, we can be conscious of these situations and adjust our judgments accordingly. In overcoming snap judgments, it also helps to focus on specific attributes of a person instead of whether they are a man or a woman.

The term "mansplaining" perpetuates this gender-based statistical bias by focusing attention on the male gender rather than the behavior. The fact that this term exists makes it more likely that people will assume someone is "mansplaining" simply because he is a man. This is not productive for men who may be trying to overcome "mansplaining" tendencies. It increases the chances that the other person will dismiss what the "mansplainer" is saying outright, giving him less opportunity to practice having conversations with people who may not be accustomed to his dominance-seeking style of speaking. Also, the term "mansplaining" distracts from the fact that women can be sexist and condescending as well.

The "mansplaining" meme has been useful for raising awareness both about the tendency of men to come off as patronizing and the tendency of people to be condescending to women. But it distracts from the real problems and perpetuates gender-based bias. To work towards a solution for productive cross-gender conversation, we should focus on specific behaviors rather than gender stereotypes and on listening rather than on pointing fingers.

Cooking for One

You there. Eating takeout at your kitchen counter, pots and pans clean and neatly stowed. Third time this week. Your taste buds are getting a little bit bored and your stomach a little bit skeptical of that recycled deep-fry oil. Why don't you cook?

What's that? You are waiting for your roommate or partner. Or you are sad because you have no such roommate or partner. Gastronomic pleasure need not be shared, you know. You can cook for one.

I know what it is like. Losing a cooking partner--especially one to whom I played a supporting role in the kitchen--was one of the more devastating aspects of past breakups. With whom was I going to invent dishes like ancho chile risotto? How was I going to have more than one home-cooked dish per meal? Who was going to test the food to make sure we were not going to die?

And I have suffered for years. I have spent more time than I would like to admit calling Tofurkey sausage, noodles, and a sauteed vegetable "dinner." I have spent more money than I would like to admit eating out because I got bored of this "dinner." "I don't cook," I would say. "Who has time for that?" Then, one day while aimlessly clicking through dating profiles of men in Israel*, I had a revelation. I could start cooking for myself. Not just stir-fries, but soups and casseroles and other things involving more than four ingredients.

Brilliant, I thought. There are so many obvious advantages to cooking for one. You can cook whatever you want. You can cook whenever you want. You can listen to whatever music you want while cooking. You don't have to worry about getting stabbed if you turn around too quickly. You don't need two people to chop vegetables! Recipes still work when you are on your own! Also, Google is surprising helpful for mitigating concerns about imminent death. (Just today, I searched "Can you combine raw tomatoes with raw honey?" I am that paranoid.)

There are some basic lessons in cooking for one. A key insight, my roommate says, is to pretend you are cooking for two and have leftovers. As cooking for two is the same amount of effort, this is an easy way to increase variety across meals. Cooking larger portions also helps you avoid the awkward situation where you are only using one quarter of an onion at a time. There are also other, smaller tricks: microwaves and ovens are great for keeping things warm for when you have to cook in sequence. Having small tupperware containers is good for both smaller leftovers and small left-over ingredients.

There are also some fun challenges: how to get variety; how use ingredients before they expire. With no one to watch, you can get creative. Have basil instead of mint? Basil tabbouleh! Don't want to buy cream just for a soup? Use yogurt instead. Want to cook pears with chiles? Go for it. Sometimes you fail--as I did today with a tomato/basil/honey dessert--but hey, no one is around to see. And who knows, you might create something amazing. My favorite creation is a cold spinach dish based on the Japanese ohitashi appetizer that uses soy and chile sauces instead of tahini. I was once told that if I invent four other dishes this good, I could start a campus restaurant.

The leftover problem also yields a nice puzzle. Most recipes seem to be for at least four people, as are the default grocery store sizes of ingredients like celery. Left unsolved, the problem is that you will have leftovers for lunch not just the next day, but the day after, and often the day after that. Choosing dishes that freeze well (for instance, soups) can help with spacing this out. You can also pretend your weeks are extended Top Chef episodes by reducing recipe portion sizes and finding different recipes for the same ingredient. Even still, you should not be surprised if there are weeks when you eat celery every day**.

But of course, cooking for one is not for every dish. It does not make the most sense, for instance, for dishes like risotto that are labor-intensive and do not keep well. These are what restaurants are for! Eating out for one is also fun--far more fun than romantic comedies would have you believe.

Go on, explore the world of solo cooking. But don't forget to come back out for a meal with a friend every now and then. Otherwise we would miss you.

* I have never been to Israel. I do not have plans to go to Israel. In denial of the true depths of my time-wasting problem, I classify this activity as "anthropological research."
** It is not clear why they sell celery in such large bunches when such small amounts are needed for soup. I am certain this is why ants on a log exists as a snack.`

Upgrading to Scala 2.10.0

Scala 2.10.0 came out recently. It has many nice features I haven't used yet, for instance type tags, and production versions of many nice features that I was already using, for instance type Dynamic, implicit conversions, and reflective calls. I upgraded my main project to it and found it to be relatively painless.

My upgrade involved the following corresponding updates:

• Updating my SBT version. I had been using an older version of the SBT build tool (0.7.7), so I upgraded that to 0.12.1. (Any version higher than 0.11.0 should work.) This was the most painful of all since SBT has changed the way its build files work. The new SBT build system is simple, so it was mostly a matter of figuring out which variables to set and how.
• Updating library versions. The only dependency that affected me was that Scala 2.10.0 uses ScalaTest 1.9 instead of 1.8.
• Updating compiler options. Type Dynamic, implicit conversions, and reflective calls are no longer experimental and now correspond to the flags "-language:dynamics," "-language:implicitConversions", and "-language:reflectiveCalls." I also added the "-feature" flag for a reason I can't remember. A small other thing is that I had to define a selectDynamic function in addition to applyDynamic for types extending Dynamic.
• Cross-version packaging. I still compile a Scala 2.9.0-1 binary for my other project because it uses Scalatra 2.0.0--although 2.0.5-SNAPSHOT is supposedly compatible with Scala 2.10.0. SBT provides nice support cross-version compilation: define your versions, make sure you declare the right dependencies based on the Scala version, and then just use "+ package" to produce binaries for all Scala versions. Here are my build.sbt lines corresponding to that:
  

   crossScalaVersions := Seq("2.9.0-1", "2.10.0")  
   libraryDependencies <+= scalaVersion(v => v match {  
    case "2.9.0-1" => "org.scalatest" %% "scalatest" % "1.8" % "test"  
    case "2.10.0" => "org.scalatest" %% "scalatest" % "1.9" % "test"  
   })  
   scalacOptions <++= scalaVersion map (v => v match {  
    case "2.9.0-1" => Seq("-deprecation", "-unchecked", "-Xexperimental")  
    case "2.10.0" => Seq("-deprecation", "-unchecked", "-language:dynamics", "-language:implicitConversions", "-language:reflectiveCalls", "-feature")  
   })  
  

For your versioning needs, you may want to investigate this version investigator that Paul Phillips wrote.

And finally, aquestion for my Scala-using friends: I have been hesitant to upgrade to Scalatra 2.2.0. Anybody have a pointer to a summary of the concrete changes I need to make to port my code?

How Science Really Works

The theme of the week is research, theory vs. practice.

This past week, the #overlyhonestmethods Twitter hashtag went viral, my friend Phil Guo published an MIT Technology Review piece on the surprising importance of "grunt work," and my undergraduate researchers learned that "research" involves a lot of hunting down compatible versions of software packages.

Indeed, life in research is not what I fantasized as a six-year-old playing "professor" with my stuffed bear and raccoon, or even as an undergraduate student deciding the next years of my life.

How I thought graduate school would be. I arrive at MIT full of energy and wonder. Professors, noticing my unique capacity for innovative thinking, pull me aside and say, "Hey you, come work with me." I spend two weeks reading papers. After that, I produce ground-breaking ideas night and day. I discover productivity shortcuts that nobody knows about: I am able to eat less and sleep less, all while producing more. The brilliance of my ideas amazes the world. I spend most of my days explaining them in a cafe with a whiteboard. After I publish several seminal papers, universities call me offering me jobs, publishers call me offering me book deals, and journalists call me asking my opinion on all technological phenomenon. I tell them phones are so passe: everyone uses SMS now. During all this, I acquire a brilliant and handsome collaborator. After we realize we are twice as productive together, we fall in love. Together, we eradicate the world's software bugs. Along the way, I also eliminate sexism, racism, homophobia, xenophobia, and dust allergies. Since there is no Nobel Prize for Computer Science, the Nobel Committee awards me the prize in Literature*. All before my sixth year of graduate school.

How it is. I arrive at MIT full of energy and wonder. Professors, betting on my capacity for hard work, pull me aside and say, "Hey you, come work with me." I spend two weeks reading papers. After that, I work night and day trying to produce a paper for a conference deadline. I discover some "productivity techniques:" I eat less and sleep less and produce more work for two weeks.  Then I burn out for two months. Despite this sacrifice, the world does not seem to care how brilliant my advisor thinks our ideas are. We have another paper deadline. My advisor gives me all feedback between midnight and the 7am deadline. Learning from this, I become nocturnal in preparation for future deadlines. I spend most of my days (well, nights) installing obscure software packages and decompiling byte code into a more complex representation of the byte code. Nobody calls or texts anymore. During all this, I learn that the two-body problem** is one of many reasons I should avoid making eye contact with male academics, lest we accidentally fall in love and into a mutually destructive future. Reality crushes my soul.

And then. I stop idealizing science. I realize that even though science is conducted by humans according to subjective standards, we can still make progress. I accept that doing research means doing hard and often unglamourous work. I learn to play the game and to sell my ideas. I also learn to combat sexism, racism, homophobia, xenophobia, and dust allergies in my own life. Most importantly, I learn to enjoy myself.

To be continued: I am still in my fifth year of graduate school.

Addendum: Readers have noted that this paints a somewhat dismal picture of Ph.D. life. I describe some more positive aspects of this experience in this other post, Reasons to Pursue a Ph.D.

* Philosopher Bertrand Russell has also received the Nobel Prize in Literature.
** The difficulty of negotiating geographically colocated academic positions.

What is Computer Science?

Every now and then, a non-technical friend--or stranger at a party--will ask me, "What is computer science?" As your typical antisocial computer scientist, I am often too tired to do justice to this question. From now on, I will carry around QR codes pointing to this post.

Computer science is the study of what machines can do for us. Among computer scientists there are theorists, applied logicians and mathematicians study what is even possible for a machine to compute. There are systems scientists who study how to get the power we want out of our machines. Then there are artificial intelligence researchers who help computers make unsupervised decisions--they are the ones responsible for the robots and the cool demos. Computer science researchers take the risk out of building systems; software engineers build the things we use.

At the core of computer science is a pile of logical foundations. People like to study how hard problems are: whether you can compute solutions in steps ("time") that are a polynomial function of size of the input, an exponential function, or something even worse. People talk about different classes of problems: for instance, P, the class of problems with polynomial-time algorithms, and NP, a class of problems for which polynomial-time algorithms are not known. It is not known whether P and NP are the same, but it would change everything if we discovered they were: all of our banking software is encrypted based on the assumption that P != NP (P not equal to NP). (A couple of years ago there was big news when somebody claimed to have proven P = NP.  Fortunately, it turned out to be a false alarm.) People across subfields talk about what is decidable: what it is possible to develop a terminating computational routine to do. This allows us to guarantee (haha!) that the software powering your space shuttle will not spontaneously freeze from getting stuck in an infinite loop.

Then there are the machines themselves. Incredible things. The invention of the transistor allowed for everything by making high (1) and low (0) signals, called bits, stable enough to build everything else on top. Computer hardware runs on bits combined into instructions and a set of logic gates (for instance: "and," "or," "not") for decoding these instructions. Instructions encode a unit of computation: for instance "add" or "store in memory" along with operands, either as constants or in as locations in memory. Memory just contains more of these bits (just 1's and 0's!). All a computer is doing, really, is reading instructions from code memory and reading to and writing from data memory. There are also details like interacting with a keyboard and a screen. One of the key ideas in systems is abstraction: building higher-level, simpler systems on top of existing ones to simplify reasoning. Programming languages shield the programmer from having to reason about bits and operating systems shield the programmer from reasoning about details like the interaction with the keyboard and in what order application processes should run. On top of all this we have the mobile app that let you read this post. Underneath, it's just bits.

And there is also the sexy artificial intelligence stuff. Back in the day, people thought they might create machine intelligence by modeling how the mind works. Now most of the routines powering robots (and spam filters and everything else) is based on statistical heuristics. Bayesian inference and fancier stuff. People who work on these kinds of things spend a lot of time thinking about how to get more accuracy out of their algorithms (for detecting faces, for predicting whether a message is spam, for planning the route a robot will take) and/or how to make these algorithms run faster. It is pretty amazing that all of the obscure stuff you might have learned in probability theory is the reason that your Facebook friend feed works.

As for me, I focus on programming languages. Programming languages protect people from having to reason about bits, or machine-level code, or sometimes even complex details of execution. Programming languages researchers range from logicians who try to make programs more correct and hackers who try to make people's lives easier. The specifics of this will be the subject of another blog post, as we seem to be reaching the limits of your attention span.

Oh, you were just trying to make polite conversation? Sorry. Maybe you can pass this along to a friend.

Resolutions and Goals for 2013

It has come time for me to publicly announce my goals for 2013 in order to shame myself into following through.

I have the following resolutions.

1. Only acquire things I will use.  Right now my "minimalism" is sustained by high object turnover: I give away things quickly to balance out acquiring them quickly.  To work towards true minimalism I will instate a two-week decision period before acquiring non-essential items.
2. Get rid of things I do not use.  I would like to keep giving away (and occasionally selling) objects that I have not demonstrated need for in the past year.
3. Only take on commitments I want and can handle.  I am happier and more productive when I want to be doing what I am doing and I have time to do a good job.  I will instate a one-day decision period for new commitments.
4. Eat well.  I would like to take more pleasure in the process of eating and focus on quality rather than quantity.  I will make time for eating in my schedule and plan ahead so I can have food that is both good and good for me.
5. Meditate.  In working towards meditating daily, in 2013 I aim to do it at least once a week. 

In 2013 I plan to keep pursuing my two main interests: 1) empowering people to be more productive through their programming tools and 2) empowering women to have the same opportunities as anyone else.

Towards improving programming tools, I have some specific goals regarding Jeeves, the programming language I have been developing for automatically enforcing privacy policies, and demonstrating its feasibility as part of a framework.  I would also like to continue spreading the gospel of statically-typed functional programming languages.  I would like to become more familiar with Scala and continue my Scala evangelism.

Towards empowering women, I am concluding my tenure as an Executive Board member of Graduate Women at MIT and would like to think about what other change I want to see.  I want to reach out to more young girls--I would love to see a framework that allows young girls to be pen pals with young women, their "future selves."  I also want to give people intellectual ammunition to defend their feminist views--for instance, in light of the Delhi gang rape death.  I will think about how this translates into actionable items for me.

Happy New Year, friends.  In the upcoming year, please feel free to discuss these goals with me to make sure I have not forgotten about them!

A Belated Brief on Barcelona

Notes from a more decadent time...

Itinerary: Barcelona with Kate, April 2012.  Photos here.

Day 1.  Arrive in Barcelona by plane close to midnight on a Friday evening.  Take the bus; take the train.  Arrive at train stop and realize map is insufficient for further direction. Take a cab but driver also gets confused.  Follow tourists on the street until I find the hostel.  Reunite with Kate, realize our neighborhood has only other tourists, and wander the streets dejectedly observing the foreign vendors of street beer and samosas.

Day 2.  Get up around 10, go to La Boqueria market, and day-drink in Montjuic amidst numerous fountains and the "most cactus garden." Descend Montjuic just in time for the magical fountain show.  Try to go to beach clubs but our friend Adnan is wearing Those Fucking Shoes.  Adnan redeems himself by dancing his way into a private function.  "Are you with that guy?  He is strange.  Here is a drink."

Day 3.  Get up close to noon, procrastinate going to the Picasso Museum, and eat a delicious vegetarian meal in El Ravel (at Sesamo*).

Day 4.  Get up at noon.  Walk past the Sagrada Familia; line is too long.  Walk past more Gaudi; admission is too expensive.  Walk around Parc Guell; drink more wine.  Meet up with a friend's friend who shows us a "real Barcelona experience."  We get Middle Eastern food; we go to some bars; we go to a club (Apolo).  At one of the bars, the friend's friend engages in a series of arm-wrestling matches with strangers.  Kate has a video somewhere.

Day 5.  Get up at noon.  Take the train to Montserrat to see the Benedictine monastery from the 15th century.  During each of my trips with Kate, there is a moment when we clutch each other in amazement.  This happened here.

Day 6.  Kate catches her flight.  While walking alone in the Miro park, I become victim to an elaborate con involving photography, cocaine and heroine, and policemen real and fake.  I can send you the definitive story via e-mail.

Out of consideration for the travelling pleasure of our future selves**, Kate and I have saved some sights for future visits.  Among these are the inside of the Sagrada Familia and the coastal village of Caldaques, home to Dali.


* Every meal was amazing.  Sesamo happened to be the one place where I took a card and so remembered the name.
** Not laziness.

Zen Living by the Rules of Soyen Shaku

In thinking about what I want out of 2013, I have become inspired by the rules of Soyen Shaku, the first Zen teacher to come to America.  Here they are, from Zen Flesh Zen Bones:

In the morning before dressing, light incense and meditate.

Retire at a regular hour.  Partake of food at regular intervals.  Eat with moderation and never to the point of satisfaction.

Receive a guest with the same attitude you have when alone.  When alone, maintain the same attitude you have in receiving guests.

Watch what you say, and whatever you say, practice it.

When an opportunity comes do not pass it by, yet always think twice before acting.

Do not regret the past.  Look to the future.

Have the fearless attitude of a hero and the loving heart of a child.

Upon retiring, sleep as though you have entered your last sleep.  Upon awakening, leave your bed behind instantly as if you had cast away a pair of old shoes.

On the Importance of Seemingly Useless Work

When I first started graduate school, an older student told me about the importance of maintaining a feeling of incremental progress. Even if you are doing seemingly useless work. This may be the best advice I ever received.

During grad school, I have found this "feeling of progress" at a macro level mostly in the non-academic parts of my life: in co-founding and seeing the growth of Graduate Women at MIT, in becoming a better, yogi, in developing deeper friendships, and in various channels of personal development.  Doing engineering on other people's research ideas during internship was also helpful.  Though it probably would have been nice to have more incremental results and feedback on my Ph.D. project (the first paper of which took three years to be published), this other progress gave me comfort that I had not been wasting my life.

Feeling progress is also powerful on a micro, day-to-day level.  The structured procrastination approach is a fantastic way of maintaining a feeling of progress.  (This essay quotes this other humorous essay by Robert Benchley here.)  The main idea is to allow yourself to do less urgent but also necessary tasks while procrastinating the task at hand: for instance, playing ping-pong with undergraduates (as part of attending to Resident Fellow duties) rather than finishing an essay.  Allowing yourself to do, and even prioritize, those tasks can make you more productive.

This all justifies my philosophy on work/life balance* (which is remarkably similar to my philosophy on eating): work when I want on what I want to work on**.  A lot of projects/tasks, personal and professional, fall into this category of "work."  Although I assign higher importance given to professional tasks and tasks with imminent deadlines, it is important to have non-urgent, non-professional items.  I have also begun assigning higher importance to tasks that easily yield high levels of progress-feeling: for instance, refactoring code and running errands.  Doing something because I want to do it, rather than because I feel like I need to, requires far less energy and discipline and also has a higher work-to-progress-feeling ratio.  (If something gets close enough to a deadline, however, I often suddenly desire very much to do it...)  This philosophy probably presupposes that I have a deep inner drive to work.  (Similar to my deep inner drive to eat.)

Progress is not so much a state of achievement but a state of mind.  I have to come to value and seek the feeling of progress as much as I do actual progress.  Not sure yet how much it is improving my output level, but it is certainly making me feel happier and more productive.

* We all know that the point of my blog is to validate my life choices.
** From a restricted set of permitted items.

Yes, I am a Minimalist.

My friends laugh at my “minimalism.” And I do not blame them.

I like things. When I was younger, I aspired to own a Nalgene in every color. I have lost count of how many computers I have. Until recently, teenage girls loved using my bathroom to experiment with all the beauty products. After seeing how much I spent on a pair of (beautiful! white! leather!) gloves, a friend once asked if I was going through some kind of crisis and wanted to talk about it.

Having things has always made me feel safe. You never know when you will run out of shampoo or need to use a second mandolin for julienning a lot of carrots in parallel or get invited to an event where not only do you have to wear a fascinator, but it has to be pink. Better to be ready.

Then three important things happened in 2010. First, substantial amounts of water leaked from our roof through our ceiling over the course of months. Second, I made friends with a minimalist. He lived in Belgium and had only one spoon in his apartment that we all shared to eat speculoos. Third, I moved out of that leaky apartment.

During this year, I learned that not only are many material possessions unnecessary, but they can also be burdensome. And so I developed the goal to actively love and regularly use all of my possessions*. And according to the minimalist blogs, the concept of minimalism has become sufficiently trendy and dilute that this definition is acceptable.

Working towards this goal has involved thinking about how to get more usability out of things. For clothing, for instance, I learned the rule that any new article of clothing should be appropriate for at least three different kinds of occasions. Versatility is the key: a few things can go a long way.

I have also been working on letting go. I acquire many things thinking that I might need them. I have gotten better at giving them away. If I have not used something for a year, I force myself to get rid of it. In the last months, I have gotten rid of multiple travel pillows, a carpeted cat toy, a second sleeping bag, a Zune, bags of clothing, and numerous books.

And, of course, I have been thinking about what is necessary. There are things I want. I want art in my living space. I want self-expression through my clothing and accessories. I want two pillows when I sleep. I want variety to my meals. Perhaps that is all. Perhaps I do not even need these.

I have been making progress. I do not have a TV. I have fewer clothes and books than I used to. I pack for most trips into carry-on luggage. Most of my cooking involves a single knife, pot, and pan.

I would love to one day live in a vast empty apartment with only a few possessions. I may realize that this will not make me happy, but I hope to never again get caught up in the acquisition of more and more things. And this is why I call myself a minimalist.

* I have also been thinking about minimalism with respect to commitments and relationships but I will not include discussion of that in this post.

Treat Yo Self: Clean Up Your Code

A couple years ago, I discovered what I thought was the shortcut to building research systems.  Forget good software engineering practice!  Forget functional abstraction!  Copy-and-paste code all over the place; modify it to fit your needs.  Thinking before coding?  So college.  After all, premature optimization is the root of all evil.

In the beginning, this worked out well.  In my first year, even my advisor told me he was impressed with how quickly I got things working.  I saw in other research code the same patterns that I was learning to adopt: monstrous tangles of functionality with scant documentation.  I have found the secret to research productivity, I thought.

A couple deadlines later, I began to feel the consequences of my actions.  Pre-deadline, systems would begin to fall apart: a patch here revealed another hole there.  Post-deadline I had no desire to go back to disgusting soups of one-off functions, barely usable in the first place and certainly not reusable.  Much time was spent either avoiding my code or writing replacement code from scratch.

In other researchers, I observed that the few who had designed their systems well were able to make quick bug fixes and extensions.  For everyone else, either their code bit-rotted in obscurity or they were a slave to maintaining their systems for barely-satisfied users.  During paper deadlines, those who had built up good infrastructure could build comfortably on previous work while others ran around fighting fires and despairing.

During the course of grad school, my relationship with my code has become increasingly important.  Clean, modular, and well-documented code (with tests!) is not only less likely to have bugs but will be useful for longer.  Clean code provides a solid foundation for you and potentially other researchers.  Modular code makes it easier to reuse parts of your code. Also, knowing exactly what your code does just feels good.

On his blog, Harvard professor Michael Mitzenmacher advises graduate students to take a day every now and then to find better tools: for organizing papers read, for recording ideas and progress, etc.  Rewriting and refactoring code has become an important part of these activities for me.  Not only is refactoring useful, but it is also a relatively low-effort way to achieve a feeling of progress*.  For me, refactoring has become a treat for working hard.

Don't tell too many people now, but I think this is the real secret to research productivity.

* The importance of the feeling of progress is a topic worthy of its own blog post.

Living on the Edge of Existence

Reading Jack Kerouac's Dharma Bums made me wonder whether my life should be more exciting.  While exploring this, I had the following conversation.

Martin: You are bored because you are not living on the edge of existence. Why don't you go travel around India with no money?
Me: I might die.
Martin: Exactly. A comfortable, safe life is boring.

Martin then tried to convince me that bourgeois comfort and safety are the enemies of an exciting life.  I started searching for plane tickets to dangerous destinations.  Fortunately, I had the next conversation.

Me: I'm trying to live on the edge of existence.
Rishabh: The thing is, I already do that. With deadlines.
Rishabh: Yesterday, I almost died.

This made me realize that different people have wildly different perceptions of what it means to live extremely.  In Dharma Bums, while the Kerouac character Ray Smith binge drinks and is essentially homeless as he hitchhikes across the country, the Gary Snyder character Japhy Ryder leads an ascetic existence of writing and scholarship.  When Japhy tells Ray about The Book of Tea, Ray says, "Those guys got high off nothing, hey?"

And so I found in Dharma Bums the answer to my question.  Japhy Ryder's life is unquestionality extreme: he abstains from material luxuries and enjoys spending time on the edge of civilization.  But Japhy carefully prepares enough food and sleeping bags for their trip into the wilderness.  But Japhy makes sure they have enough time to get where they are going before dark.  And Japhy lives fully and enjoys beauty as much as anyone: he is lucky to be able to get "high off nothing."

To live on the edge of existence, one does not necessarily need to abandon absolute comfort and safety. It is certainly easier if what is around you is new, interesting, or a life-or-death situation. But over-approximating the boundaries of existence is just one way to live on the edge. Through mindfulness and conscious consumption, it is possible to find the edge with greater ease and accuracy. Challenging oneself and demanding precision can be as thrilling as fighting for survival. This approach certainly seems more sustainable: while Jack Kerouac died young of alcoholism, Gary Snyder is still writing today.

A comfortable and safe life is boring, but comfort and safety are relative and personal. Introspection and thoughtfulness could go further towards living fully than impulse-buying tickets to somebody else's adventure.

On Productivity in Grad School

I was recently invited to be on a panel about being productive in graduate school.  This invitation surprised and flattered me.  I do not consider myself to be particularly productive as a graduate student: there are graduate students who have far higher-volume research output and/or greater publication count.  I also don't follow the productivity rules: I don't always remember to track my progress; I don't have a great way of organizing papers I read; I often work on what most catches my attention.  And I spend a good deal of time doing things that are not my research.

That said, I seem to be getting by decently well.  I am happy with the work I have been doing and my papers are in good venues.  When I am in a serious thinking or building mode, itemized goals are not always necessary.  Sure, being more organized about papers would help, but for many topics I am interested in I can give you a short bibliography off the top of my head.  High-level goals usually keep me focused and deadlines can make certain tasks seem pretty damn interesting.  Outside of research, I co-founded Graduate Women at MIT in 2009; we now have over 50 planning committee members running programs serving our over 1200 mailing list members.  This has taught me enormously useful lessons about collaborating with peers, managing people, and managing my time.  The time I spend traveling, doing yoga, and enjoying life with friends also contributes to my happiness and creativity.

Reflecting upon this, I realized that productivity looks different for everyone.  Unlike many people I consider productive, I find it difficult to make myself work.  If I want to work, nothing can stop me; if I don't want to work, then I am better off waiting until I want to work.  To want to work, I need to feel like I am working on something meaningful: technically interesting to me and potentially impactful to the world.  I also refuse to sacrifice a certain quality of life in favor of work: if some end goal requires me to work harder than I would like, then that goal is not for me.

For me, learning how to be productive was about understanding how to harness my motivation and focus it towards productive endeavors.  Below I elaborate on my "top five" strategies that I was asked to discuss at the panel.

1. Figure out what drives you.  When I am uninspired, I can spend weeks pretty much running in place.  When I am inspired, it is scary what I can do in even one hour.  If you have experienced this, you will agree that the difference between inspired effort and uninspired effort is immense.  Some people are driven by a desire to understand something, others are driven by a desire to create something, and yet others are driven by more abstract goals: a desire to be influential; a desire to be "successful."  Many people are driven by imminent deadlines.  Knowing what you are going after and why you are doing it will make it easier to find those moments.
2. Stay away from rat races.  Being in a position where you are constantly measuring yourself up to other people is exhausting and, in my opinion, inefficient.  Find your niche; make yourself irreplaceable.  This will give you the freedom to come up with ideas and work at a more leisurely pace.  Discover what topics and groups of people you have the most mutual "chemistry" with.  Figure out what you have that nobody else has--this can be a skill set or a deep interest in some topic.
3. Learn the rules of the game.  Invest time in figuring out what matters, what doesn't matter, and the relative mileage about different things you can do to achieve your goals.  For instance, I have also been told that your top three papers matter more than how many papers you have.  I have also become increasingly aware of the importance of publicizing work via talks and personal meetings.  I now spend up to one month preparing a talk; if you told me as a young graduate student I would later be doing this, I would have found it preposterous. 
4. Optimize your environment.  Take time to configure your programming environment, your bibliography collection tools, your way of recording ideas/research notes, etc.  Surround yourself with smart and productive people who motivate you to do good work.  Know the people in your network--a quick e-mail to an expert in a subarea can quickly point you to the most relevant reference materials, saving you days of paper-reading.  Similarly, being in an environment where you are discussing your ideas with peers you respect will make it easier to do innovative research.
5. Take care of your body and mind.  Learn how to hack your body; one hour of work when you are on top of your game can be equivalent to hours of less high-quality work.  Eating, exercising, sleeping, taking breaks, spending time with friends, and meditating are the solutions to most problems.

A caveat is that this advice is best-suited for those similar to me: workaholics who prefer doing to thinking.  And of course, who knows how good this advice is, as I have yet to really prove myself.  As my own productivity is a work in progress, I welcome what advice you may have.

Related reading:  For those of you who struggle with traditional productivity advice, Structured Procrastination is a nice essay.

Should You Learn Scala?

It depends on what you want to accomplish*, but the answer is probably yes.

By way of background, Scala is a programming language originally developed at the Swiss university EPFL in an attempt to apply recent innovations in programming languages research to a language that can gain mainstream traction.  Researchers keep coming up with clever ways to it easier for programmers to write correct code and to write less code, but much of the time only academic programmers benefit because these features are implemented in boutique languages (for instance, OCaml and Haskell) that are not in widespread use in industry or open source projects.

On its own, without considering features such a libraries and interoperability, Scala is a nice language.  It is "multi-paradigm," supporting object-oriented programming and functional programming idioms.  Scala allows you to define types associated with both data attributes (with classes behaving like C++/Java classes) and behavior attributes (with traits corresponding to Java interfaces).  In the way of functional programming idioms, Scala functions are first-class (which means you can pass them around as values) and Scala also supports anonymous functions and currying (partial application of multi-argument functions).  This combination of features make it possible to write Scala programs that are quite concise and elegant**.

Scala's libraries and interoperability make it a force to be reckoned with.  Scala runs on the Java Virtual Machine (JVM) and can interoperate nicely with Java code.  This means that you can use Java libraries directly from Scala code.  It is also possible to call Scala code from Java (see here).  There is a nice post about how you can take advantage of Scala parser combinators, which use higher-order functions to help you write concise parsers, to write parsers for systems otherwise written in Java.  Not only can you do all of the things in Scala, you can easily write part of your program in Scala and the rest in Java.  (This is huge for mainstream adoption potential because so much of the world's code is written in Java and so many developers are taught in school!)

Learning Scala will make you more marketable.  Many companies are using Scala these days, including LinkedIn, FourSquare, Twitter, and Quora.  The founders of Quora spent a couple of months building a Scala web framework in order to use Scala.  Martin Odersky, the man behind Scala, is now behind the startup Typesafe for supporting Scala development.  There are some nice Scala web frameworks out there, including Lift and Play.  Scala is also gaining traction in the research community.  Many more people cared about our research on the Jeeves programming language for automatically enforcing privacy policies once we implemented it as an embedded domain-specific language in Scala.

Scala is also relatively easy to learn, especially compared to other strongly statically typed languages (OCaml; Haskell).  I have previously said that Python is the most marketable language for beginners, but I am beginning to change my mind.  Like Python, Scala has clean syntax, nice libraries, good online documentation, and lots of people in industry using it.  Unlike Python, Scala also has a static type system that can prevent you from doing bad things (whereas in Python the bad things just happen when you run the program).

If you are teaching a course using Java, you may want to consider switching to Scala.  I have recently had positive experiences teaching Scala to MIT undergraduates during recitation in 6.005, the software construction course taught primarily in Java.  During three recitations I introduced how to use functional idioms, how to build an evaluator for a simple language by using data types and pattern matching, and how to build an incredibly concise parser for the tiny language using parser combinators.  You may find my notes here, along with the accompanying code examples.

If you are considering the merits of Scala over other languages, you may also be interested in reading my Quora responses to the questions "What makes a good programming language?" and What are the advantages of Scala over C++ and Haskell?.

* If you are building scientific applications, a language with more math support (Matlab; Mathematica; R) may be superior.  If you just want to do a weekend project writing a Craigslist scraper, Python may be better because it is easier to learn and has great web scraping libraries.
** Okay, Scala programs are not as beautiful as OCaml or Haskell (I have another post on ML vs. Haskell) but it's so much more practical in many ways.

Simple Advice for Being Effective in School

As a result of hijacking a few recitations in MIT's 6.005: Software Construction course to evangelize Scala, I have come into contact with numerous undergraduates.  Engaging with these students, I have realized how much more effective I could have been during college were I less focused on my work and more focused on things like showing up on time.  I have come up with the following list of things that go a surprisingly long way towards academic success.

1. Show up.  It goes without saying that you miss a lot of things if you don't show up.  There is also a two-way thing.  If you don't get face time with an instructor, it does not matter how good you are.  They are not going to know who you are, they will probably feel less motivated to answer your questions, and they will probably not write you a recommendation letter.  (I am not important enough to have written many recommendation letters so I am extrapolating a bit on the last one.)
2. Be on time.  During the first few minutes of a lecture/recitation/talk, many important things happen: there might be administrative announcements; there might be high-level motivation; there might be contextualizing facts.  If you show up late, it is more difficult to motivate yourself to pay attention and to follow what is going on.  You will often miss other things when you spend the whole time trying to catch up.
3. Stay awake.  The more you are able to absorb directly from the person who is trying to convey information to you, the less unnecessary self-teaching and work you will have to do later.  If you are not able to stay awake in lecture, hack your body (get more sleep, drink more coffee, move your body before lecture) until you learn how to stay awake.
4. Be present.  Focus on being in the classroom rather than surfing the web, doing other homework, or zoning out.  Paying attention, not just to the lecture/exercise but also to other students' responses, can save a lot of work.  I have noticed that students do a fair amount of unnecessary work because they did not listen to either verbal or written instructions or because they missed the answer to another student's clarifying question.  Getting enough sleep helps a lot.
5. If in doubt, ask.  If you don't understand something, it could probably be explained to you better, either by the instructor or by another student.  Asking makes it more likely that you can get this explanation.  Also, instructors like to see effort.
6. Be curious.  It is great to ask "what if" and "why" questions.  Instructors love this and they will remember you for it, as long as you are not being obnoxious.
7. Find the motivation.  Knowing why you (personally) should learn the material will help you with 1-6.  Do not be afraid to ask the instructor what the current topics are good for in the real world and what mastering the current content can do for you.
8. Don't be lazy.  Read instructions.  For programming classes: look up syntax and try things out with the compiler/interpreter.  Your TA might like to be there for you, but you are better off trying things on your own.  You will not always have a TA in the real world.
9. Be nice.  How smart you are often matters less than how nice you are.  For instance, the instructor will be much more likely to answer your questions thoroughly if you are nice.  
10. Be a commitment minimalist.  If you have so many classes and extracurricular activities that you are not able to accomplish 1-9, cut down.  Many people have told me that they would have gotten a superior college education had they had done less and focused on it more.

In summary: school is often not about how smart you are, but about how much you are participating as an engaged human being.

How to Give a Talk Where I Stay Awake

I fall asleep during lectures. I have even fallen asleep during one-on-one meetings. While I am not proud of my poor attention span, it has made me think about what makes a speaker compelling. Here are some actionable items from my observations.

Develop rapport with your audience. If your audience can identify with you as a human being, they will have an easier time listening to you. There are many ways to establish rapport: for instance, by making eye contact, by making jokes, and by identifying things you have in common with the audience. Anecdotes--especially those from your struggle in coming up with the solution--are great. Treat the audience as potential supporters rather than potential detractors. Avoid being defensive.

Address your audience’s interests. In How to Win Friends and Influence People, Dale Carnegie says you should prioritize the other person’s desires and interests in conversation. For instance, the standard advice for technical talks is motivate the talk with respect to the questions the audience is interested in. There are also other dimensions of audience interest. For instance, some audiences may be interested in having everyone understanding all parts of a talk, whereas others may prefer talks with an obscure section that only a few experts understand. The interests need not be relevant to the topic at hand: for instance, internet kittens in addition to operating systems.

At least pretend you are having a two-way conversation. Speak at a reasonable pace.  Make eye contact.  Pause before and after the important points to give the audience time to process. The most engaging talks I have seen involve the audience without derailing the talk. This is done through asking questions the audience already knows, asking the audience to solve small problems, or asking the audience for questions. Strategically injecting opportunities for audience questions is the most lightweight way of achieving this. Skilled speakers may even moderate some amount of discussion.

Keep things interesting. Give a talk you would want to attend. Entertain. Tell a good story. Make slides that someone would want to look at (as little text as possible, with text as large possible). Make a cool interactive demo. Be outrageous.

Convey passion. If even you do not feel strongly, why should we care? Show this by putting energy into your speaking and/or by saying why you find something interesting.

In summary: focus on what the audience wants to hear rather than what you want to say. This is easier to achieve if you are comfortable with what you want to say. Prepare well. It is not uncommon for among my peers to run through a 20-minute talk at least five times. Being comfortable with your talk allows you to focus on establishing a connection with the audience and paying attention to their needs.

I hope to take some of this advice in my upcoming lectures and talks. Perhaps then I will not have to resort to throwing candy at those who have fallen asleep.

FAQ: Applying to Graduate School for Computer Science

Over the years, I have gotten various e-mails asking me about what it is like to be a graduate student at MIT and how to apply.  I have compiled this list of frequently asked questions.

--

Q: What is the best school for studying computer science in the United States?  Where should I apply?
A: The top-ranked schools are MIT, Carnegie Mellon, Stanford, and Berkeley but the best school for you depends on many factors, including the area(s) you are interested in, the professor(s) you would work with, the size of the school, the size of the department, the location of the school, etc.  I would recommend applying to all schools you may be interested in and then talking to potential professors and their groups once you are admitted.

My personal notes from visit weekends at MIT, Carnegie Mellon, Stanford, Berkeley, University of Pennsylvania, and University of Washington can be found here.

--

Q: Can you tell me about the work in research group X?

A: The best way before applying to get a sense of what is current in group X is to look at the websites of the professors and  the graduate students.  The group itself may also have a website.  After you are admitted, you will have plenty of opportunity to talk with professors and students to determine what is the best fit, either through the visit weekend or over the phone.

--

Q: How much work is the Computer Science Ph.D. program at MIT?

A: The course requirements tend to be lighter than other Ph.D. programs: I had four required courses and two additional for a non-CS minor.  (They may be changing this.)  The focus is on your research: as long as your advisor thinks you are doing good work and a couple of other professors can confirm this, there is not too much bureaucracy to deal with.

As for research, you are technically expected to do at least 20 hours of work for your advisor and 20 hours for coursework/your own interests.  I would say the average student should expect to work 40-60 hours a week, depending on how well they use their time and how demanding their advisor is.  The number of expected hours varies by student and by group.  I work on average 40 hours a week if there is no deadline, 50 hours a week the month before a deadline, and 60 hours right before a deadline.  I would imagine the amount of work expected of MIT students is comparable to that at other top computer science Ph.D. programs.

My blog posts Reasons to Pursue a Ph.D. and The Life of an Academic, Explained may also give you insights as to what life at MIT may be like.

--

Q: Could you look over my personal statement?
A: Unless I know you personally, I probably do not have time to look over your statement.  Here is some good advice, most of which was given to me by others:

• Your personal statement should be an answer to the question "why should we admit you and what would it be like to have you here?"  You should argue convincingly for the first point while also giving an idea of your research interests and research personality.
• Someone should be able to read your statement quickly to answer the question above.  Reading the first sentence of each paragraph should give someone a pretty good idea of what your statement says.
• Leave out unnecessary details from your statement, especially if someone can find those details on your resume.
• Be as concise as possible.
• Don't use excessively flowery language.
• Start early and revise often.  Show your statement to anyone who will read it and ask for their feedback.

I have posted one of my personal statements here.

--

Q: What advice do you have for me on my resume?
A: Here is some good advice for resumes:

• Try to be as concise as possible.  If you are applying straight from undergraduate, there is little reason why your resume should exceed one page.
• Use action verbs, state your achievements clearly--all that standard advice.  People should be able to quickly be able to evaluate the contributions you made in each role.  I prefer having 2-3 bullet points per role to clearly communicate this.
• Ask other people who have graduated from your institution and/or people you have worked with to look over your resume.  They will have the best idea of what people expect and how it will be evaluated.

--
This is one of my "applying to grad school" blog posts.

1. Deciding to Apply
2. Standardized Tests
3. Fellowships
4. Applications
5. School Visits
6. Some notes on picking grad schools/advisors
7. FAQ: Applying to Graduate School for Computer Science

You may also be interested in these blog posts I have written:

• Reasons to Pursue a Ph.D.
• The Life of an Academic, Explained
• How Science Really Works

Glitter is How I Fell in Love with San Francisco

The mid-twenties women of my peer group all have one question on our minds.  Especially if we are in tech.  Should we move to San Francisco?

I had been living in San Francisco for a few weeks (during an internship) when a friend asked if I was in love with it.  "No" was my immediate response.  Not yet and maybe not ever.  People are so laid back, I said.  All I do is work and commute (from the southern Mission to Menlo Park, 45 minutes, twice each day).  Where are the intellectuals?  Where are the Europeans?  Why is everyone so outdoorsy? And why is it so cold?

I subsequently had several conversations about why I was not in love.  Try to like it more, my other friends said.  You of all people can figure out how to enjoy yourself there.

And so I started spending more time in the city: wearing scarves and finding the flat places to bike.  I went into the uniquely American natural beauty of California's mountains and redwood groves.  I went on hilly runs with breathtaking views of the city and the water.  I ate sushi; I ate pork belly; I ate everything.

One night I acquired loose glitter to wear to what a new friend and I thought was a theme party, what but turned out to be a play party.  (Only in San Francisco...)  The next night I asked the friend if it was okay to continue wearing the glitter.  She laughed and said, this is San Francisco.  You will never be the weirdest person on the street.

One day I acquired a metallic blue cape.  When I asked the woman at the store if it was okay to wear it "right now," she laughed and said, this is San Francisco.

What a good way to describe the attitude of the city, where you can do whatever you feel inspired to do without judgment.  People describe their lives in terms of projects rather than professions.  The CTO of a high-profile tech company is also a yoga instructor.  You can wear a suit or patterned pajamas.  Men, at least in the Castro, are equally likely to be naked or wearing nun costumes.   You can have conversations with strangers on the street.  This is San Francisco.

I remember when I first realized I was falling in love.  After a night out and little sleep after, I biked from the Mission to the Sunset for a leisurely few hours with old friends.  I felt so alive biking back through Golden Gate Park in the sunshine: satiated by an incredible Mexican brunch, wearing a newly-acquired thrift-shop jacket, still covered in last night's glitter.

Glitter is how I fell in love with San Francisco.  I still do not know if I should move there--but what a beautiful affair.

---

Note: My descriptions do not apply to the South Bay/Silicon Valley.  I am in love with neither the South Bay nor the commute to and from there from the city.

Why Do Women Want to "Have It All?"

Last week, former State Department director Anne-Marie Slaughter's Atlantic piece "Why Women Still Can't Have It All" spurred a flurry of internet discussion: there was a nice response on why "having it all" is the wrong thing to be striving for (see the Salon response) amidst many other responses (see the NYT summary and Joanne Wilson's response).  This discussion brings up the valid point that the set of desires of "elite women*" may be unsatisfiable.  The main problem is that the outdated expectation for a woman to pair with a socially "stronger" man does not necessarily create professionally supportive relationships for ambitious women.

The assumption that the man needs to be professionally superior leads to situations in which the woman will spend more time thinking about the family.  A mentor once made the provocative statement that that if I did a startup, I would no longer be able to find a man who I respected.  When I asked why, he said that I am "biologically wired" to look for a "stronger man."  After a fair bit of self-reflection, reading about evolutionary biology, and talking to both men and women, I concluded that this "stronger man" business is based on societal constructs left over from a time when society did not allow women to provide for themselves.  I have encountered quite a few men whom I respect who have also said they are willing to make significant sacrifices towards having a family, including staying home if necessary.  I am not saying that ambitious women can only be with less ambitious men, but they should be aware of the topography of the choice space and the tradeoffs that different choices entail.

Professionally ambitious women must also make a choice about what they want to optimize: it is likely that women seeking both "power coupledom" and supportive relationship will be disappointed.  It seems that part of the desire to be part of a "power couple" is based on expectations from the days when a women did not work and a woman's success was based on how "well" she married.  In those days, ambitious men did not expect to find equally successful women: they looked for a supportive woman.  Women should be able (and allowed by society) to make this choice as well.  Women should realize that while it may be the ideal to find a successful man who is also has the bandwidth to be supportive (professionally, emotionally, etc.), this is unlikely as the selection pool can become quite small.  We can be quite happy, however, if we choose to optimize for one or the other with no illusions about what we are giving up.

It is important for a woman to realize that if she wants a "stronger" man, she should have expectations about the tradeoffs she is making.  This does not mean, however, that all women with careers must make these tradeoffs.  We have been given one view of what it means to "have it all" and it is our responsibility to question and redefine this for ourselves.

My friend Yao inspired this post with the following comment:"I wonder why women always think they must be the ones to give up their career for kids and not their husbands."

* I acknowledge that these discussions are highly heteronormative and have a relatively small target demographic.  Everything I say probably applies only to young, urban, highly-educated, heterosexual American women.

Why I Go Out

My friend Neha sent me this piece Why Go Out, in which Sheila Heti compares going out (to bars, clubs, parties, and the like*) to a cigarette habit, discusses the merits of being alone, and concludes that social interaction may be a necessary evil. While I agree that people should be honest with themselves about why they go out (to fill voids; to avoid knowing themselves), going out can provide more than just a quick fix for the voids they may be trying to fill.

I agree with the idea that being with people makes you addicted to being with people. I have found that when I have been surrounded by people, I feel more lonely when I am alone. When I have a roommate, I desire social interaction more than when I live alone. I find it important to spend time alone in order to establish the equanimity of being alone as a home base. Spending much of the week "out" certainly gets in the way of self-reflection, self-knowledge, and self-friendship.

Going out is more than a quick fix for me: it is an important part of my character development and well-being. Because of the public persona I find it important to maintain, going out forces me to act happy and carefree. Going out gets me out of my head and keeps me in practice of making small talk. It makes me realize I am not the only person in the world and that my problems are irrelevant to most people. I often feel more confident, happy, and agreeable after being out than after spending time alone or even with a close friend.

Establishing a productive framework for going out takes commitment. The more you go out, the more you get invited out, and the more people you meet. This makes you more statistically likely to attend better parties and have better friends, based on whatever definition of "better." A couple of years ago I established the rule "always go out" for weekend evenings. This has caused dramatic improvement in not just my social life but also my productivity: I am feel much happier and more creative now. Everybody wins.

And so I go out, not just out of habit, but to establish habits that bring more human connection and happiness. Yes, I would sometimes rather be at home, but it does not mean that being home is better for me.

* The "going out" Heti talks about seems to describe a specific kind of going to bars to drink and to pick up people. I also find that fairly empty and depressing; I can see how it can be addictive. As a graduate student in Cambridge I am lucky to have found the "party circuit" of grad students who go out and are also nice and interesting people. Being able to so easily "go out" among friends is not the norm.