Stalk and Snipe These Computational Social Scientists

There’s a number of academic job searches at great schools this year for positions around computational social science. While my two-body constraints will keep me rooted in Boston through 2016 which keeps me from applying, I’ve had several folks reach out to ask for advice for candidates they should seek out. Because interdisciplinarity has a weakness in failing to provide a focal point around which worthy candidates can be lauded by peers, I thought this might be a great opportunity to enumerate those peers whose work and thinking around computational social science and variants thereon (social computing, network science, etc.) I really respect — and thus should be included in hiring committees’ binders full of men or women!

This list is drawn from conversations with colleagues, interacting with people at various conferences and workshops, or getting to know through other channels like Twitter. As such, this is not an exhaustive search and is necessarily biased by friendship, shared interests, and shared memberships but I’ve made some minimal effort to eschew obvious conflicts of interest arising from prior collaborators and shared affiliations (which disqualifies a whole bunch of awesome people who have worked alongside me with Darren, Nosh, and David!). In their defense, the people below did not ask nor were they informed about being on such a list so it should certainly not be interpreted as self-promotion or unhappiness with their current position. And with such an ad hoc methodology, it’s certainly incomplete and I apologize in advance for omitting people.

I’ve broken the list up into two categories based on where they are in their careers. The first is “Stalk” for folks who are too young to be on the job market yet, but are up-and-coming rockstars who I’m confident will be in high demand once they are on the market. Keep an eye on them and if you’re able to, these are folks to pick up for as interns or visiting students while you can before they migrate to the next category. The second category is for folks who are in the vicinity of the academic job market and should be directly targeted for recruitment, or “Sniped.” There’s obviously a third category of junior people who already have jobs in academia or industry who could be stolen, but I wouldn’t presume to speak to their interest in such a conversation!

I present the inaugural job market Stalk and Snipe list in alphabetical order.



How not to run a (academic) hackathon

I think the academy and academic conferences would do well to incorporate more of the hackathon ethos and norms into its stodgy and plodding culture. So I like hackathons, I really do. But I wrote much of the following response to an email discussion about how to make an hackathon successful and I would also like to get other folks’ thoughts since my experience with hackathons is both limited to a few cases and biased towards cases that are more academic-focused. This is my read on the cultural norms and best practices and are almost certainly internally inconsistent. However with those disclaimers, here are some of my thoughts on why I’ve seen hackathons falter. This is mostly a list of chipping away everything that doesn’t look like a successful hackathon, rather than an affirmative list of how to make a hackathon successful. 

1. Thematically underconstrained. While a strawman, “Let’s get together and scrape some Twitter data!” is the surest way to have a hackathon crash and burn. There needs to be some combination of the following: a documented dictionary, cleaned data, or a clear method, and always some defined site, question, or outcome. Taking each of those in turn, a hackathon might do any one of the following: go explore a canonical dataset like GSS, ACS, or AddHealth for geospatial data; take messy Reddit data and have folks clean and code it up using some extant framework; allow people to learn some SNA concepts using Wikipedia data. The point is there are clear boundaries about where the hackathon starts and stops to prevent people from being paralyzed at the outset by questions of scope, but people are free to pursue a variety of agendas, methods, and questions within those constraints.

2. Mis-distribution of technical expertise. This can arise from either having not enough people with the requisite skills or permitting technical people to self-select into working with other technical people. The result is the people who know how to scrape, process, and build are either overworked or not pushed out of their comfort zone. Hackathons absolutely demand a willingness to learn new methods and techniques — people who rejected out of hand the possibility of learning to program, design, or do basic statistical tests obviously should not be invited. However, it’s also unrealistic to think that people are going to pick up Python scripting in a few hours so there should be repertoires of activities that allow non-technical folks to clean data, code data, search for related work and documentation, do UEX and wireframing, etc.

3. Regression to the academy. Like any other profession, academics want to revert back to comfortable paradigms. However, a hackathon should not become a lecture with technical folks teaching others to do basic scripting, a troubleshooting session around a single person’s bug, or airing of concerns and quibbles over a method or approach. The overriding focus should be on getting something done (even poorly) rather than talking abstractly about how things might be done better. The format should be radically participatory and resist a focus on deliverables, authority, or schedule.

4. Over-ambition. To the extent the evocativeness of the portmanteau needs construction, hackathons are not meant to be quick or lightweight. It’s not something that happens in a 90 minute session, it should not be a filler between other activities, and it should not have to compete with alternatives that require less commitment. The hackathon will have no expectations of “success” and people shouldn’t be expected to continue the work outside of it. There’s both a floor (~3 hours) and a ceiling (~10 hours) on how long people should be able to work in a day and these hours should be clearly communicated.

5. Lack of respect for participants and their time. As an organizer, a hackathon is not an opportunity to get a bunch of people together to do your coding work for free. You do not let a bunch of folks sign up under the auspices of one theme, then switch it at the last minute to another. You do not forget to have enough space, power, beverages and food, or other support for the people who are volunteering their time and expertise. You do not fail to have the authority to protect the space from ideologues, influence peddlers, or people with toxic personalities by intervening or ejecting people if necessary.

6. Unclear rules. This is probably best done as a group, but there are basic procedural questions. What are the norms about people tweeting, taking photos, or emailing colleagues about what they’re doing in the hackathon? Will people be able to continue to use this data or code afterwards and under what conditions? If individuals have non-public access to data or other resources, how obligated are they to contribute that to the hackathon? Who is responsible for cleaning up afterwards? Does anyone need to be compensated for space, food, etc.? Are people allowed to work on or access each others machines? What kinds of services will we use for collaboration and how can we accommodate others who don’t or refuse to use those services (e.g., gDocs, Dropbox, etc.)?

What are others’ thoughts? Have I missed something basic here about the culture and ethos of hackathon culture? Does anyone have good affirmative or positive advice on how to make a hackathon successful?

ICWSM in Cambridge

After six weeks of travel that took me to Rio for WWW, Hamburg for Sunbelt, Copenhagen for NetSci, Chicago for hooding, Alaska for a wedding, Bloomington for PolNet, and St. Louis for another wedding, I am grateful that I don’t have to travel for ICWSM which will be at the Media Lab in Cambridge next week. For those of you unfamiliar with my adopted hometown, I wanted to share some of the sights, bites, and swigs you should check out while here.

Cambridge is the “city of squares” and any intersection you’ll find is a “square” named after one person or another. The bounding box for squares you should check out while here are Kendall Square (closest to MIT), Central Square (the primary commercial and transportation hub in Cambridge if the name didn’t already give it away), and Inman Square (the northeastern-most outpost). The Kendall Square area has changed dramatically since I graduated in 2006, so there is much to explore if you haven’t been back in a few years. Central Square has a “unique” flavor and inhabitants, but some excellents restaurants and bars. Inman Square isn’t terribly convenient to reach via public transportation, but has a number of great restaurants.


Definitely check out the MIT Museum as well as the Museum of Science if you have a chance — both are excellent. If you want to be a hardcore tourist, then doing a duck tour is essential as it’s conspicuous, interesting, and fun.

Cambridge also has an interesting mashup of club cultures — if you’re into indie music, then you’ll want to stop by the Middle East or All Asia or if a more traditional club music is your scene, then Middlesex Lounge is right across the street.

If you’re around Sunday afternoon, make sure to check out SOWA in Boston — arts, food trucks, and farmers market.


For breakfast and coffee, I would recommend: Flour (halfway to Central Square on Mass. Ave.), Voltage on 3rd St. (about 5 minutes east of the Kendall/MIT stop), and Cafe Luna (also in Central Square).

For vegetarians, the notoriously granola People’s Republic of Cambridge has a number of excellent options. The Clover foodtruck located in the street behind MIT Medical next to Kendall T-stop, Veggie Galaxy (diner-style food) and Life Alive (juices & salads) in Central Square. For dinner, Helmland (Afghan) and Similians (Thai) near Lechmere or Rangzen (Tibetan) or Baraka (African) near Central or Oleana near Inman are amazing.

For lunch options, you’ll probably end up at the food trucks next to the Kendall T-stop at least once: the lines for Momogoose (asian) and Clover (vegetarian) reveal the preferences of the crowd, but there’s typically also a Middle Eastern and Mexican food truck as well. Firebrand Saints has a really cool video deconstruction installation that’s worth checking out in addition to the sandwiches and roast chicken. There’s also a Chipotle, Au Bon Pain, & Cosi in Kendall if you absolutely must have culinary homogeneity.

For upscale or foodie options, Craigie on Main, Salts, and Cuchi Cuchi (near Central Square) are going to be your best options. Legal Seafood checks the upscale box, but locals generally do not go out of their way to go there for seafood especially when there’s places like Alive & Kicking Lobsters which is out of the way but worth the trip for the freshest lobster rolls. For outstanding high and low Mexican cuisine check out Ole and Olecito (respectively) in Inman, for Southern check out Hungry Mother or Tupelo in Inman. There are a few Asian and Indian places around as well, but none that I would particularly recommend.


If you’re a beer snob, there are two notable places worth checking out. Meadhall is just around the corner from the Media Lab and has dozens of beers on tap and some very solid but expensive food. If you’re looking for a more intimate gathering, finding some unexpected beers, and exploring a bit more, then Lord Hobo near Inman Square is for you. Bukowski’s in Inman Square also has an excellent tap lineup and lots of space for groups. More traditional pubs like Atwood’s or The Druid can also be found in Inman. If you’re a cocktail snob, you’ll want to check out Brick & Mortar, Rendezvous, or Green Street, all of which are in Central Square.