Hack Mobile: A Successful Hackathon Failure
(Disclaimer: The word "hackathon" was used way too much here, but there's no synonym other than "coding competition" so we're all gonna have to live with it)
Earlier this month, Qualcomm organized their annual summer intern hackathon: Hack Mobile. It was an event that I'm pretty sure almost all of my fellow interns were excited for: hackathons are perceived to be the skeleton of many tech students' careers, and I'm no different.
I've written and spoken about my hackathon experiences many time, so much so that my former high school classmates know me as "the hackathon girl." I typically consider myself to be a hackathon expert, merely due to the fact that I've attended nearly a dozen hackathons, co-founded and been head organizer for four different hackathon organizations, and become a large part of the NYC hackathon scene. I tend to share advice with my teammates about the kind of information they should share about themselves to the judges and how to structure and presentation/demo so that it captures the eye of even the most non-technical person. I'm always confident that my team and I will build something to some higher degree of completion, present it relatively gracefully, and walk out of the venue with a sense of satisfaction (and normally a prize of some kind, even if just for winning the cup-stacking competition).
Hack Mobile was different.
Photos courtesy of: Robert Wolff
@sdrobertw on Twitter
This was my first truly corporate hackathon. My first hackathon event (called the AppNexus Hackathon, if I remember correctly) was held at and sponsored by AppNexus. That's normal—giving the title of "Hackathon XYZ: Sponsored By COMPANY" is even something that I do with my own hackathon's sponsorship packages. When a company supports your event so thoroughly, you have to give credit where credit is due.
However, Hack Mobile was an event all about Qualcomm. Don't read that as though I'm saying it was a bad thing: Qualcomm flew out regional interns to compete, hackers got to spend the night at the Qualcomm campus, and there were no additional sponsor company employees walking around trying to talk to people (which is great when you're in the mood to network, but not when you're in the mood to hack).
The event was even structured around the Qualcomm work day, starting at 6 PM on July 6th, right at the end of the work week.
Around 250 attendees from all of Qualcomm's offices (but of course predominantly from the San Diego headquarters) were placed in The Spot cafe, sitting side-by-side at 4-person tables. Before the event even started, my teammates and I made sure to grab a pile of the snacks stashed around the space, because the most important activity during any tech event is snacking.
The premise of the event was to use one of the three Qualcomm technologies that had been workshopped to us in the weeks leading up to the hackathon:
- Qualcomm Dragonboard 410c
- Snapdragon 835 VR Development Kit
- Qualcomm Neural Processing SDK
I only went to the Dragonboard workshop, mainly because I knew that I wanted to work with a piece of hardware, and the Dragonboard has a composition similar to that of an Arduino (something I've successfully built on). Despite this preparation, my team walked into Hack Mobile essentially blind. We hadn't taken any time to sit down and think about the product we wanted to make, mainly because we didn't know the scope of the Dragonboard and the various sensors that would be available to us.
To my roommate Aliya's credit, we spent an entire car ride home discussing possible ideas, and I ended up shooting down every one because of the lack of hardware. Don't get me wrong, they were great ideas and would be a success at any hackathon, but they were software-focused. I wasn't much help either, because the hardware-based ideas I had were either too complicated or required research/data that we didn't have access to nor would be able to understand.
My team had thought about meeting up earlier in the week to brainstorm at least somewhat, but we're a distracted bunch. We tend to spend more time joking around than getting work done, so it made more sense to us to sit down individually and ideate, rather than spend an hour or two being unproductive (but having fun!) together.
Before the kickoff ceremony, Aliya and I ran through a list of potential APIs to use and what they could possibly be used for, and when the time the rest of the team (our friends Elaine and Pooja) arrived, we sat down and went over the list while eating a dinner of rice, beans, chips, and, most importantly, guac.
We had a list of ideas (none of which we felt too strongly about) and checked out the Dragonboard and a ton of wires, sensors, and LEDs to stock up on supplies. By that time, the cafe we were all staying in had started to get hot and stuffy, as our fellow hackers started to kick their work into high gear.
I'm someone who needs people and their white noise around me to be productive, which is why I spend my days at school basically locked in Cornell's Duffield Hall on the engineering campus. On the other, I can't be elbow-to-elbow with people for 16 hours straight.
My team felt the same, so we grabbed our stockpile of laptops, chip bags, and Grove sensors and made our way to an empty conference room. It was cooler (temperature-wise, and now that we had taken over the room, vibe-wise), open, and had a wall of whiteboards: three pros to outweigh the con of having to sneak up the stairs so as to not to alert the other hackers of our precious find.
It was still early in the schedule (around 8 PM?), so we continued to brainstorm. You can never have too many ideas, right?
I had a lot of fun taking notes while we all threw up a tech-focused stream of consciousness, but we ultimately settled on a device that would alert the user subtly about their nearing proximity to a dangerous area. The device would feature a bracelet-like string of LEDs for the user to wear around their wrist. Rather than take out their phone to check where they are in relation to a more dangerous location, the LEDs would slowly become redder to indicate proximity to a zip code with a high-crime rate.
The technology we were planning on using was a Dragonboard, a Grove touch sensor, LEDs, the Google Geolocation API, and a crime-rate API. As the resident ECE on the team, I tasked myself with dealing with the hardware exclusively.
The rest of my computer-science-majoring team was more than happy with that delegation.
I walked into my tasks with an open mind—I had worked with an Arduino at the last hackathon I attended, as well as spent the previous semester coding a FRDM board for my Embedded Systems course. I knew the Dragonboard would be different, but I was confident in my ability to Google, peruse StackOverflow, and read various product documents.
I had no idea what I was getting into.
By around 10 PM, I was set in my station. I had my personal laptop set up in addition to the monitor and keyboard I needed to use to program the Dragonboard's Linux system. The black briefcase and plastic containers littered around me contained the sensors and wires and LEDs I was using to test the board's pin connections, input/output readings, and power supply. I made several trips to that floor's coffee machine for my drug of choice: hot chocolate. I was listening to my focus mix of hard rock and emo music, and my hood was pulled tight around my head.
I had all of the elements I needed to be in my zone, but nothing was clicking for me.
I started off with Qualcomm's video tutorials on setting up the monitor, keyboard, board, and power supply. I thought all of the correct lights were on and that everything was powered up and connecting, but then I would move the Dragonboard to one side and the monitor would turn off.
After figuring out that my problems were due to a loose power supply connection (as most hardware problems tend to stem from, in my experience), I moved on to written walkthrough of the Dragonboard written by Major League Hacking (MLH), a global hackathon organization. that not only offers a Qualcomm-based hardware lab at their events but whose team I know personally (hi, Shy!). I ran through the steps but couldn't get past writing a function to make a simple LED light up. I couldn't figure out if I was misunderstanding the pin diagram, accidentally programmed the wrong pin to as an output, or if the light was burnt out.
It wasn't the LED being burnt out or power not getting to the light, so I tried everything I could think of to debug. I took out the hub of ports, which is used as an addition to the board so as to allow it to be connected to more sensors and extensions, from the Dragonboard so I could work with it directly. I wired and rewired and rewired some more, trying every single combination of voltage, ground, and input/output pins that I could. I switched from working with an LED to working with an LCD screen, which needed a clock line (SCL) and data line (SDA) as inputs, as it was an Inter-Integrated Circuit (I2C) device.
I spent hours sitting and saying nothing to the rest of my team, who was off in another corner of the room trying to understand Google's geolocation and why it needed to where cell towers were. I was focused intently on trying to work my way through the hardware, because I knew I had the experience, knowledge, and drive to make something work.
When my experience, knowledge, and drive started to wane, it was around 1:30 AM. My teammates felt the same, after spending so much time trying to verify the APIs, google errors, and write functional code that didn't throw the same inaccurate location result. They had made progress, but my frustration with my part of the product was palpable.
Usually, even if my team is strapped for time and won't finish our vision, I encourage them to stay up for hours to still make a decent MVP for the judges and fellow hackers to see. There's always a way to cut corners and shave down features that won't compromise the main facet of the product. That kind of mentality normally leads us to go to bed at our tables around 4 AM, knowing that we only need to work on some finishing touches when we wake up in four hours.
But when I'm in that situation, it's almost 1:30 AM and we've been hacking since the afternoon. Each team member has something to work with that, even though it isn't complete, is past the preliminary stage of trying to figure out exactly what the hell they're working with.
What I'm trying to say is by 1:30 AM the goal is to actually have worked your way through a tutorial and customized it in some way, even if only slightly. It's only then, at least in my experience, that finishing a working prototype is possible.
The hackathon was slated to end at 11:30 AM, at which time we and the other teams were meant to present a working demo to the judges. Everyone on the team knew that we wouldn't make that deadline with a quality, working product. It wasn't enough time. We were exhausted (everyone) and angry (me) and loopy (everyone). Nothing would get done past this point in the night (or, if you're being annoying like me, the morning) and we were all on the same page about that fact.
And I'm sad to say that, by 2 AM, we had left the Qualcomm campus. We packed up our room, cleaned up our mess (right as the cleaning crew came in), and turned in all of our tech.
We weren't alone in our early migration; out of the approximately 60 registered teams, I heard that only 30 finished and presented. The room that was full of college students not even six hours ago had half of the people it once held. The mentors and campus team sat at their respective tables, looking tired to the bone.
I felt bad as we walked away from everyone and into the cool night air, but I knew we had made the right decision. Staying up the rest of the night would've been fruitless, considering how little we had done and how much it had taken for us to do it. We most likely still wouldn't have finished, or would've had to turn in something that would frankly be shitty. We would present our submission while almost falling asleep, as some of friends told us happened to other teams. We would've crashed and slept until 7 PM, wrecking our sleep schedules for the upcoming work week.
I've always believed that the main purpose of a hackathon is not to win, but to learn something along the way and leave feeling satisfied. I hate backing down from a challenge, but I'm not lying when I say that I left Hack Mobile satisfied, satisfied that I had tried working with the Dragonboard, satisfied that my team had come up with a cool concept that we can't wait to tackle again, satisfied that I had taken my physical well-being into account when in the context of a hackathon, a notoriously sleep-deprived event.
Hack Mobile was an event that, although didn't add another win to my hackathon tally, was an overall success of an experience.
