Impressions on judging a Hackathon
A Berkeley CS undergraduate I know who is passionate about hacking asked me this summer if I would be a judge for this weekend’s Cal Hacks hackathon—being on a panel that would select the “top 3 overall” projects from among the top 12 finalists identified in a first-round of judging.
I spend a lot of time in Soda Hall and you can’t go a month without seeing flyers for some new hackathon or programming contest up on the student bulletin boards. Never having experienced one, I agreed to do this, and I’m certainly glad I did.
The overall winning hack was extremely impressive: a team of six students reverse-engineered the radio protocol for the remote control that drives a quadcopter drone, programmed an Arduino with radio board to be the controller, connected that to a Myo armband so you could control the copter just by arm gestures, then went further and used EEG-style electrodes to allow it to be controlled by your thoughts. Even though this has been done before, the fact that six students did it in a weekend is remarkable, especially (to me) the hacker ethic embodied in their attitude that they shouldn’t be limited to controlling the drone using the manufacturer-provide remote control. (I summarize a few of the other top-12 projects at the end of this post.)
Here is the “CS professor’s take” on this event. TL;DR: to my faculty colleagues, I’d say if you are asked to be involved in one of these, you should do so at least once; many of us who ended up as CS professors started as passionate hackers, and it’s important to understand what forms and manifestations that urge takes today and how we might be able to support them. (It is definitely alive and well.)
This event is huge. Over two dozen companies provided financial support, and not just swag and hardware for hacking on, but travel expenses to/from Berkeley for accepted participants (there were over 1000 people from all over the place, mostly the US & Canada). The event was held in the various facilities of Cal Memorial Stadium. Nearly all day on Saturday, both companies and student groups offered one-hour “crash courses” in using particular tools or technologies (JavaScript, d3.js, specific site APIs or hardware product SDKs, etc.). Most teams who built a hack around a particular hardware product got to keep the product, whether they placed in the final ranking or not. Teams who did make the finals also got additional prizes: swag, hardware, and especially…
Recruiting. More than one company offered as a “prize” a paid field trip to shadow an engineer at the company for a week, or a mock (or real!) interview with the company. A few high school students were even present, which should be a recruiting opportunity for Berkeley as well!
The students are amazingly creative. True, some of the projects amounted to little more than just another social network, but there were many creative ideas, both software-only and hardware+software system. One team, Transliterate.me, created a custom iPhone soft-keyboard that lets the user type in phonetic sounds using a Roman alphabet and converts them to the appropriate symbols for Arabic, Simplified Chinese, Sanskrit, and a couple other languages. Parcelly is a “peer-to-peer parcel delivery system” based on the Uber model (and using Uber’s API to schedule deliveries and pickups). Myo Fighter connected Myo armbands, worn on both arms and ankles, to an emulator for the once-famous Street Fighter arcade game, so you can play Street Fighter by actually doing the body motions, a little like Wii on steroids. Scribble is an Arduino-based servoing pantograph that slaves one pen to another wielded by a human drawing on a 2d surface. Splash is a p2p messaging system for use at protests and other crowded events where data coverage or Wifi are unavailable: it sends PGP-encrypted messages point-to-point by building and managing a Bluetooth route network over the devices of people who have the app. Fashion asks you to “rate” different types of clothing based on various attributes, and then recommends items you might like.
At the same time, I wish I could’ve advised some of the teams before they started hacking, because they sometimes tended to reinvent some wheels out of naïveté. Splash’s routing algorithm was prone to the same attacks as unprotected wide-area IP routing (false route advertisements, etc.) but the students were unaware of this work and reimplemented naïve versions of those algorithms. The recommendation algorithm for Fashion was a set of simplistic heuristics, even though well-known algorithms for collaborative filtering are available in library form. None of this is to detract from the students’ effort and work, but I couldn’t help but wonder if those of us who know the field a little better could add some value on the front end by pointing students to at least the existence of technologies and algorithms they could use.
On the popular yet annoying game show Who Wants To Be a Millionaire, contestants are allowed a limited number of calls to one of their “lifeline” colleagues during game play to ask them about the answer to a question. I wonder if future hackathons might allow hackers the equivalent of one or two “lifeline” calls to a panel of industry/research/faculty experts in various areas in order to get just-in-time advice on tackling a problem in specific areas of their hack (maybe there are existing algorithms or even libraries they don’t know about, etc.) The only problem would be getting these “lifeline” folks, most of whom probably have lives and families, to be awake from midnight to 8am on a Friday and Saturday…
Lastly, I would’ve liked to see their code. Judging was based on technical difficulty, creativity, social impact, and similar factors. I wouldn’t expect the code to be beautiful or anything, but I would like these students to be aware that while hackathons like this certainly develop their ability to learn about a new tool/technology/API/whatever and then rapidly apply that knowledge in prototyping something, that is a different process from actually producing an artifact that will be used in production and must be maintained. (And you can often tell a lot about someone’s internal design process from looking at their code.) There is absolutely a place for hackathons, and I’m all for them, but I also want students to learn to distinguish “hacking mode” from “careful design and implementation mode”. Maybe they already do, and my concern is for naught.
It was cool that Joel Spolsky (cofounder of StackOverflow and ) gave 10-minute opening remarks, talking about how debugging (vs. writing the code) takes up 2/3 of your time in hackathons and 98% of your time as a professional programmer, and described Two Things Real Programmers (vs wannabes) Do: divide-and-conquer debugging to narrow the bug down to a small piece of code, and using the “scientific method” to formulate a hypothesis about what’s going wrong in that piece of code and then writing tests/harnesses to check that hypothesis. ”People who get flame-broiled on StackOverflow usually forget to follow one or both of these steps,” simply posting their entire program or an entire long incomprehensible stack trace without having put any apparent effort into narrowing down what is going on. (I’d like him to give this talk in CS169!)
Either way, these are a thing, and judging by the many hundreds of participants and their level of energy during the judging presentations after being awake for the better part of 36 hours, students love them. (And companies clearly love them too, as you may have guessed.) We should be figuring out how to maximize the value of these experiences on students’ ongoing CS education. That’s a subject for a faculty lunch discussion, which I’ll report on here after I initiate it.
A few other projects I saw demos of, not mentioned above: Multipass is 2-factor authentication for teams. (“We could have modified OAuth, but we preferred to write our own 3rd-party authentication protocol in Erlang.”) Control lets you program gesture controls based not only on body accelerometers but on GPS position and orientation, so the same gesture can be context-tuned to different physical locations/environments. Oahu is a BOINC-style “donate cycles to help solve big problems” that runs entirely in-browser: just having your browser open and the extension enabled lets you participate. Myo Man combines Myo controllers and Oculus Rift VR headset to let you fly around in a virtual world like Iron Man by making the same gestures he makes (think of Superman when he’s flying).