Research Hackathons

Here's an idea inspired by hackathons – intense one-day to one-week periods where people work together on a project — and by pair programming.

As a professor leading a research group, pretty much the only one-on-one time you get with each grad student is a one-hour weekly meeting. You're on a manager's schedule, and your students are all on maker's schedules. Each student grinds for a week, meets with you to deliver a status update, absorbs your scholarly wisdom for an hour, and then goes off to grind for another week. Repeat for four to six years.

Of course, your student might send you email if they get stuck mid-week or spontaneously pop into your office to get more feedback. However, in my experience, most students (especially early-stage ones) are unlikely to take the initiative to bug their advisor, who always appears way too busy and overbooked.

This common mode of advisor-student interaction leads to three main sources of student unhappiness, all of which I've witnessed during grad school:

• Getting stuck – If your student is receiving high-level feedback only once a week, it's incredibly easy for them to get stuck on something mid-week, especially when dealing with the nitty gritty of their daily grind. The classic example in CS research is that something sounds wonderful in theory when you pitch it at a meeting, but is extremely hard to implement in code.

• Feeling isolated – The Ph.D. journey is inherently a lonely one. Students often feel like nobody understands or cares about their research. And a weekly thumbs-up from an advisor isn't enough emotional support. Prolonged isolation kills morale, motivation, and productivity.

• Becoming estranged – Worst of all, students can grow estranged from their advisors since what they do every day (hacking and grinding) is so different from what they see their advisors doing (talking and writing). Many grad students view professors as super-busy people who spend all day attending meetings, delivering lectures, and writing endless emails, reviews, and grant proposals. And meanwhile they're down in the salt mines trying to install the necessary Python packages or debugging statistical models originally written by a long-gone former postdoc who never documented his SPSS code.

Now here's an idea that could alleviate these problems without taking up much of your time. I've never seen this done before, so I have no idea whether it will work. But here goes ...

Research Hackathons

Once every few months, clear your schedule as much as possible for two consecutive workdays and spend that time one-on-one with a single student. For those two days, move that student into your office, and work alongside them on their project. Think of this experience as a two-day research hackathon.

Here's how this simple idea combats the three aforementioned problems:

• Getting stuck – By fully immersing yourself in your student's project, you can understand the details of their workflow and provide constant feedback to get them unstuck. For example, when you notice your student doing something inefficiently in code or know of a software library or statistical trick that works better for their circumstance, you can point it out immediately. You have so much implicit knowledge about the details of getting research done that can't be conveyed in a high-level meeting but naturally comes out when working side-by-side with your student.

• Feeling isolated – A research hackathon can lessen your student's feeling of isolation because it shows that you care about their project in a tangible way. Giving weekly praise upon hearing their progress report is fine, but devoting your time to working alongside them feels much more gratifying (to both parties). And when your student sees that you too get frustrated by the nitty gritty of the grind, they won't feel as alone in their struggles.

• Becoming estranged – The bonding effect of an intense hackathon can prevent you and your student from growing apart, despite your perpetually busy schedule. It shows that you're both willing and able to do the sorts of work that you ask them to do – that you lead by example. Professors who aren't afraid to get their hands dirty once in a while can command more respect than those who appear aloof and out of touch with what grad students do on a daily basis.

I'd love to hear feedback from professors. Are research hackathons a good idea, or am I hopelessly naive? What can go wrong?

(Update on 2014-02-14: As an alternative, replace weekly meetings with a two-hour passive pair programming session.)

Potential objections

“There's no way I can clear my schedule for two full days. Do you know how busy I am?!?”

You don't have to be in your office the entire time, so it's okay if you sneak away every few hours to teach or attend meetings. The important thing is that you've devoted those two days to your student, so that they can feel comfortable interrupting you anytime when you're present without first scheduling a meeting.

“How much can you possibly get done in just two days?”

I obviously don't expect an entire project to get completed, but this burst of intensity could be the kick that your student needs to build up momentum on their own.

“I thought my job was to be an advisor, not to be down in the trenches with the students.”

Think of your two-day hackathon as a 16-hour period of concentrated advising. By getting down into the details of your student's project and agonizing over the grind together, you'll be imparting so much wisdom and know-how that would never come out during a casual chat.

“Pssh, my valuable time is better spent on other tasks ...”

A two-day burst (repeated a few times per year) seems like a modest amount of time to spend training and boosting the morale of one student, who will be working with you for four to six years.

“Uh, I don't want to get my hands dirty anymore. I transcended the grind a long time ago ...”

Fair enough. This idea isn't for everyone.