How to Hate your Computer in 36 hours—The Hackathon Experience

How to Hate your Computer in 36 hours—The Hackathon Experience



It’s 6 AM. I haven’t slept for 36 hours. The same bug has been screwing up my code for the past 3 hours. My teammate is yelling at his laptop with his hands tugging out his hair. Pizza and stickers are sprawled all across the table. I’m just thinking about how well this hackathon is turning out.

For those who haven’t had the wonderful experience of attending one, a hackathon is basically where programmers of every skill level go to get free food, free t-shirts, and make awesome projects (but mostly to get free t-shirts). Generally, the event lasts 24 to 36 hours at an university. Contestants form teams and build the coolest idea they can imagine, whether it’s an Android app, website, or piece of hardware. After teams have presented their projects to all the judges, the best teams are awarded. Sponsoring companies like Facebook, Google, and Twitter also give out prizes for the best use of their technology. If you don’t come back with a lot of free goodies when you go to a hackathon, you’re doing it wrong.

A couple of hours before the start of PennApps (a student-organized hackathon at UPenn), my teammates and I came up with an exciting idea: an Android app that lets users easily schedule tasks in their Google Calendar. Basically, I wanted something that would tell me when to do my homework, because I’m far too lazy to figure that out on my own. Eager to make the best hack of the weekend, we dove in headfirst (but of course, not before grabbing 10+ free t-shirts and a few Philly cheesesteaks).

As the group member most familiar with Android apps, my job was simple: make the app look pretty. You’d think this would be easy enough, but I felt ready to smash my fist through the monitor after the 10th time some text view was placed in just the right position to screw up the entire layout. After a few hours of playing with the menu design and picking the right shade of green, things started coming together, and I thought we were sailing smoothly.

Hackathon rule #1: if you think things are going well, you’re doing something wrong. It turns out that the front-end design to this app was straightforward. However, creating the actual scheduling part of our scheduling app wouldn’t be so easy.

First, we’d have to understand how to use Google Calendar’s Android API. Next, we’d have to create a simple algorithm that fit tasks nicely into a calendar. With those basic pieces done, we’d take the user’s voice as input and create a task in the user’s calendar. Of course, that would also mean we’d also need some way to figure out the important details of a task from the user’s speech. Oh, I forgot to mention that we still wouldn’t know how to handle weird occurrences like a 20-hour task due in five minutes or a big project that needs to be broken into several smaller pieces.

Inspired by our own laziness, we decided to handle the scheduling function by using an algorithm that searches through the user’s calendar and schedules the task at the earliest open block of time, giving the illusion that the user is proactive and actually has other things to do with his/her life. If the task is too large, then it’s broken up into smaller pieces that can fit into the available openings. Nicely enough, this solution also worked well with Google Calendar.

With scheduling done, and just under 6 hours left in the hackathon, we were on to the final piece: analyzing speech input. We enumerated all the possible types of input: “assignment due at 5 p.m. today, will take 1 hour”; “project due in a week”; “HUGE TEST, FIND ME 12 HOURS TO STUDY!” Ok, so maybe that last one wasn’t so plausible, but as long as we used a general script, the app was working well. Then, just because we wanted to make our lives harder, we decided to allow users to give more intricate due dates than “tomorrow”. The instant we added those three little lines of code, everything came crumbling down. Due dates of any kind were wildly off. Occasionally, the app would completely refuse to schedule simple, 1-hour tasks. To make things worse, our scheduling algorithm began to misjudge whether or not a calendar had open blocks of time.

After hours of searching, I found that we always scheduled tasks on the same week. When I had homework due Monday and it was already Tuesday, our app thought the homework was due yesterday. The bug that caused us so much misery only took 5 seconds to fix. Luckily, while I was scrambling to find the bug, my other teammates had been putting the remaining pieces of the app together. With 30 minutes left, we scrambled to come up with some cheap name and submitted our final project. We were done.

The demos came and went quickly, but I was far too mentally dead to hold a conversation with any of the judges. We didn’t win any prizes this time, but that’s not why we came here. In the end, I was extremely proud of the app we had created. It was something that I could legitimately use to help me with my life, and I could put it on my résumé.

Now, I’m working with some more friends on a web version of the app and continuing to make the algorithm even better. And this weekend, I’ll get to experience the rush all over again at UT’s very own HackTX. Keeping your eyelids open after 30 hours of work just so you can find the 10,000th bug in your code might not seem exciting, but I promise, the euphoria of seeing a project grow from an idea to a tangible app in just one weekend is worth every last keystroke.

A final note: Though sign up for HackTX is closed this semester, they’re still taking volunteers and need as many people as they can get (more info at However, TAMUHack (held at A&M, info at is still taking sign-ups, so if you want have an amazing experience like I did, now’s your chance!

Statistics in Medicine

Science Nobel Prizes 2014