A note to future hackathon organizers
Reflections from Tufts Polyhack, October 23–24, 2015
Some four years ago, I attended Tufts’ first hackathon put on by Marshall, and it changed the course of my life in a pretty profound way. Seth Drew, Teddy Cleveland, Alex Daniels and I built an app we called RaptorScheme, which was some handwritten html, css, a violently altered D3 example we mutated for our purposes, and some python scraping to get course data.
It was really bad, but it was also shockingly good given that we had been writing code for a timescale of weeks. I remember how, knowing no javascript, let alone D3, Seth and I spent the wee hours of the morning decyphering each of the 300 lines of D3 example code vaguely related to what we wanted to do. We read each line out loud and pondered what it could mean, argued about what was going on, and finally, triumphantly, developed a sufficiently accurate mental model of how it all worked to alter it for our purposes.
That experience probably contributed pretty deeply to my becoming a Computer Science major, and so four years later, as a senior, it only made sense for me to organize this year’s hackathon.
Sometime in late July, I messaged a few people I knew were interested. Soon, we moved our conversations to one larger thread. Going back to the start, it seems deeply appropriate that the first message was about…
Over the next three months I learned a ton. The purpose of this article is to distill that knowledge into 15 lessons I learned and associated steps to take to put together a successful hackathon.
Step #1: Get as many people to buy in to your hackathon as possible, sooner rather than later.
Hackathons at Tufts have a strange history. It seems that, following in Marshall’s footsteps, hackathon organizers at Tufts each year have spontaneously appointed themselves and then maybe invited two or three friends to help them. The obvious disadvantage to this approach is that each hackathon has basically started from scratch.
In what I hope will be remembered as foresight, we built a HUGE team of organizers — about 20, with varying levels of committment to the idea. But even our core group of organizers was 10 students: 3 seniors, 4 juniors, and 3 sophomores, which means that there will be at least 7 seasoned organizers when fall 2016 rolls around. At the very least, this was a good idea because we threw the biggest and best hackathon Tufts has ever seen, and that was exclusively because of how many organizers wanted it that way.
Step #2: Build a Snazzy Website and get a Good Logo
Masha Andreyeva, a friend of mine and a talented designer, offered to help me with this project over the summer. Since the vision for this hackathon was that it would continue and grow, not just be a one-off, we decided to borrow the previous year’s logo and name, to set a precedent for continuity for next year’s organizers.
Last year, Sam Purcell and James Downer put together the first Polyhack, and we wanted to build on their vision: a hackathon for the many, for the newcomers, for anyone with any idea. A polymorphic hackaton. Polyhack.
Bella Oriella put together their logo. It’s beautiful, simple, and powerful, and we wanted to work with it as a foundation. So Masha got to designing, and used the same open source font (Tesla) and the same name, but worked on revitalizing the background. Over the course of many drafts, she came up with what would become our logo.
Working with her design as a base, I started to put together the website. With this design, two ideas came to me very quickly: First, we would draw the triangles on the website with SVG by Snap.js, and second, we would animate the text of Polyhack using a library I’d come across a little while before called vivus.js (for reasons which will become obvious to you once you click that link). This required a surprising amount of work, because merely exporting the logo as an SVG was by no means whatsoever sufficient to getting vivus up and running. But after just a few too many hours of trying to figure out the internal workings of vivus and the SVG format, it clicked, and we got the animation to work. We ended up with this website, which I’m quite proud of:
A third idea came to me then, which was to have the triangles appear sequentially. After experimenting with that for a while, Masha convinved me that it was just too much visual noise. So then we arrived on the idea of shimmering triangles.
To get the triangles to shimmer, we would need to set an animation on each of them, at different times, to bounce their opacity down, and then bounce their opacity back up, and then repeat, forever. This turned out to be fairly hard to figure out how to do. Animating the opacity down and then back up was easy, but getting it to do so again, as soon as the previous animation has completed, out of sync with all the other triangles… well, lets just say I had to actually use some hard computer science knowledge and extend underscore.js with this rate-limit addon (which doesn’t actually work, so use this modified one instead). Once all of this was put together, the result was mesmerizing. Anything less wouldn’t have been enough for our hackathon. Feel free to fork the code!
Step #3: Get Sponsors early, get them to pay early.
We reached out to a lot of sponsors. More specifically, Richard Kim reached out to a lot of sponsors. He mastered the cold-email, and we got some companies I never would have thought would be sponsors, including Bohemian coding (makes Sketch 3) Bt.tn (which was a huge hit) and a couple others. But most of the money came from reaching out to friends and recruiters at big companies we knew. The Googles and Facebooks of the world have hackathon budgets for each school, so we quickly found out that Google had allocated $1500 for hackathons at Tufts. Once we convinced Kim Stabile, our recruiter at Google, that we were the only game in town, Kim gladly made those funds available to us. With Facebook, we convinced them to open such an account for us. On the phone, the way they phrased it was they were buying into this in the same way they might buy in to a “promising blind date”. That was us. Kind of cute, and definitely promising.
We started fundraising in early August for an event in late October, which is about two and a half months in advance. That is not far enough in advance for a big hackathon, we discovered. All the money arrived on time for the hackathon, but we obviously needed to spend money before the hackathon occurred, and so we had a to ask the CS department at Tufts to front the money for us, which they did gladly — that’s how they’ve done it every other year. But it would have been much smoother to get our own funds before we made the orders.
We raised money at four tiers: Bronze, Silver, Gold, and a Title Sponsor.
Silver sponsors volunteered $1k or more, Gold was $3k or more, and our title sponsor, Paytronix, put $5k towards the hackathon. Each of these tiers was initially roughly double what it settled out to be. I didn’t really have any numbers to go off of, and so improvised 1k/5k/10k which then became 1k/4k/8k and finally settled down to 1k/3k/5k, at which point we immediately picked up a title sponsor, and then had another inquiry into the title sponsorship, which we had to turn down. Does that mean we sold ourselves short in the end? It’s hard to tell, but I don’t think so. Think hard about how much money you need, and how much it’s appropriate to raise.
Step #4: Find an appropriate space
In the past, Tufts’ hackathon has been at 200 Boston Ave, which is down the road a little ways from Tufts, which means that only the strong of heart and warm of jackets would trudge the half mile to the hackathon (which usually takes place when there’s snow on the ground). Only the committed would make it there in the first place, and the curious usually skipped it, something we wanted to change this year.
This year, when we began discussing what might make an appropriate space, we immediately fell upon 574 Boston Avenue, a newly constructed building, aptly named the CLIC: The Collaborative Learning and Innovation Complex. The Hackathon could hardly have a more appropriate home.
When school began in early September, some of us visited this pristine new building and reported back to the thread. The photos made us all pause for a brief moment, and then boil over ecstatically. It was perfect. It was beautiful. Our hackathon would be amazing.
Step #5: Start telling people about it
This is probably one of the areas we didn’t do as good a job on. No one took ownership of this from an early stage, which meant that it didn’t get done until people started complaining at one another during organizer meetings that it hadn’t been done. Finally, Alice put together a facebook event.
Meanwhile, one of our silver sponsors, Cimpress, had agreed to sponsor with promotional materials, so we had beautiful posters to put up around campus, courtesy again of Masha.
But we could have done more. I’m not entirely sure what more we could have done. I’m only coming to realize how hard a problem marketing is. The problem, simply stated, is you want to get people who have an assorted set of information distribution channels they value at varying levels to hear your message and value it highly. One part of that is working on the message, but that’s the easy part. The harder part is feeding that message into the appropriate channels, tailored to the people who will receive it from those channels. How do you get people to care about something they don’t know about yet?
Most of marketing, it seems to me, always begins with this chicken and egg problem. In the context of our hackathon, it looks like this: the more people who attend the hackathon, the better it will be for everyone. You don’t want to be the 10th or even 100th person at the hackathon, you want to be the 400th. But supplying the first 399 is the challenge.
Step #6: Get a good registration process up and running
Many hackathons, especially the biggest ones, will build their own custom web solution to this problem. We decided that on this front, we would just defer to Typeform, which is extremely well designed and robust. There’s a very specific point where it is more worth using an off-the-shelf solution to a related problem than building your own custom solution. That decision calculus is a huge part of being an engineer, and of putting together anything at all, really. We made the right choice here, but I sometimes wonder what could have been.
You might notice that we had a lot of designers attend this hackathon, and I want to highlight that, because we had a rather unique approach to designers which was entirely the result of Bruno Quiroga’s hard work.
More on that later.
We were rather suprised about some of the answers we got on Typeform. For example, this blew us away: nearly two thirds of our hackers were first timers. When we saw that figure, we had to pause and rethink what this hackathon was going to be. We had anticipated a 50/50 split, or perhaps a slight bias towards more experiences folks, but as the responsese kept rolling in, it became clear that this hackthon would be about teaching and learning.
In that vein, we used a TA system called HalliganHelper which is used extensively at Tufts Computer Science, which is simply a queue of people needing help with CS problems. That allowed people who signed up as mentors to walk around, find students who needed help, and assist as well as they could, which kept the mentors pretty busy throughout the night.
Step #7: Delegate, Delegate, Delegate.
Organizing a hackathon requires a certain volume of hours in order for it to even exist. When the number of hours required to bring something into existence is too great for an individual to muster, they build an organization of people to spread the workload. Organizations require some operational paradigm, which as it turns out, is a well-studied field. I haven’t studied it, but here are my observations.
When a certain amount of work needs doing in order for something to happen, and multiple people are committed to getting that done, there exist three kinds of people in your organization, each with their own interface. These are those three interfaces:
- The person buys in to the vision of the hackthon and takes ownership of it. Without having to ask them, they perform critical functions and make integral contributions to the success of the event. They take initiative.
- The person buys in to the vision of the hackathon, but does not take ownership and waits to be assigned a task. However once they are assigned that task, they take ownership of the task and you can count on it being done, and done properly.
- The person might buy into the vision of the hackathon, but waits to be assigned a task. Once they’re assigned a task, they ask for help for each sub-decision and action that comprise that task, in such a way that it would be much more efficient for you to go and perform that task yourself. They learn from this, hopefully, but roughly twice the time is spent on this task.
On the organizing team, I was blessed with a couple people who fell in the first category. The majority fell in the second category which was good. Sometimes some people fell in the third. That was difficult.
If people make it clear that they are members of the second category (which most are, it seems) then the solution is to delegate work. If you can break down the problem into roughly equally sized chunks and distribute those chunks, and count on those chunks being accomplished, then you can effectively spread the work across people in an organization.
To a control freak like myself, this was really frightening. Nevertheless, it was vitally important to the success of the event, and worked very well once I was able to relinquish control over the hackathon.
For example, Logan handled coffee, and when he was assigned that task, he just ran with it in a way I didn’t think possible. He bought fresh beans, a grinder, and rented 4 coffee-making devices. We even rented a literal keg of cold-brew for the wee hours of the morning with a pump and all.
Max Bernstein took initiative and handled tickets better than any of us probably could have: he used our e-list and sent out personalized QR codes and built a webapp to scan them at regsitration, which dramatically sped up registration. Even big hackathon like HackMIT do name lookup in a google sheet. This was orders of magnitude faster, and much cooler.
And then Bruno worked on the designer’s experience at the hackathon.
Bruno wanted to make hackathons a place for designers as well as hackers, which they traditionally aren’t, because designers just can’t provide much value while hackers are working out the implementation details of some idea throughout the night. Designers can usually sketch out the design and UX flow much faster than a coder can implement it. So Bruno organized an amazing parallel series of events for designers he called “Design Wars” which ran through the night, so that after designers had helped out specific teams starting off, they would have a way to compete for swag and hone their skills on design problems brought to us — mostly logo-making.
The results are incredible. At least 15 designers competed in all three design wars and stayed overnight in the hacking space, designing away. You can see some results below:
Step #8: Get massive amounts of swag
If advertising the event was our weakness, this was definitely our strength.
We raised a lot of money for this hackathon, and whenever the opportunity to get more swag came along, our general attitude was “why not?” It was justifiable because we want the Polyhack brand to grow stronger and stronger, to begin a new culture of hackathons at Tufts, and so getting our logo in as many places as possible just seemed natural.
Shirts, stickers, pillows, fish-eye lenses, hoodies for organizers and sponsor representatives, and even mugs, which were sadly delivered late, and now I need to find out what to do with 300 mugs in my house.
We ordered shirts from BlueCotton, because they have amazing customer service and our hackathon has trusted them for years. Two years back, the Tufts hackathon shirts were misprinted in some way, and BlueCotton overnighted proper shirts at the eleventh hour free of charge and saved the hackathon. We owe them a lot, and we’ve gone through them every year.
Once we had our design, we found two tees we liked, and I ordered one of each of them with the design, to try them out before making the big order.
I made a few mistakes here.
- In order to get a proper demo unit from BlueCotton, you have to actually talk to them over the phone. I ordered these without talking to them over the phone, which means we weren’t reimbursed for the demo units when we made the larger order.
- BlueCotton has two printing techniques, digital printing and screen-printing, the second of which they use for orders over 25 units or so, and is much nicer. Screen-printing adds more actual material to the shirt, so when we printed it digitally, the TR401 looked bad but felt good, and the aa6005 felt a little heavy, so we went with TR401, but when we got them in the mail (screen-printed this time instead of digitally printed), the fronts felt a little plasticky, and the shirt was so thin that they ended up being a little scratchy. We should have chosen the heavier, thicker shirts.
Step #9: Set up the event
You’ve been organizing for nearly three months and today’s the day.
The hackathon is here. Time to set up the space.
We did registration on the ground floor, with the handy check-in system Max built, at which point sudents would walk up the stairs to get their shirts and then walk up more stairs to get to the auditorium. Alice was very impressed that we had a normal distribution over shirts.
We set up a room for organizers and tables for sponsors. Props to Kate Wasynczuk for figuring those out on short notice. An hour before sponsors showed up, we still didn’t know where to put them, until Kate made the executive decision to just put them on the tables in the middle of the fourth floor and that was that.
Kate also set up the Twitter, which helped us keep in contact with hackers:
As hackers trickled in to the auditorium on the fourth floor, excitement began to build, among the hackers but also among the organizers. We had made it. The hackathon was real. People were excited. Now time to get the whole thing underway.
Step #10: Short and sweet opener — don’t bore your hackers!
I’ve been to too many hackathons that feel sponsored. That feel like you’re being sold to the companies sponsoring the event. That feeling comes from many aspects of those hackathons, but one of the foremost is when sponsors get really long presentations at the beginnning of the hackathon that people just aren’t really interested in. So we wanted to keep the presentations short and sweet: no slides, unprepared and candid, our sponsors just got up and talked about themselves.
Most heartwarming was Paytronix, who’s president, Andrew Robbins, stood up and talked about his early days programming computers in the 80s and 90s. Their presence at our hackathon was deeply comforting for us, because despite this being their first hackathon, somehow all of the Paytronix guys just kind of got it — they understood what we were about and what we were doing this for, and for that we were deeply grateful.
We got everyone excited, told everyone the rules, had sponsors present, and the whole thing was over in 30 minutes! People streamed out to get started, and the excitement was veritably palpable.
Step #11: Food is the fuel for a hackathon, it’d better be good!
Arthur and I disagree about a lot of things, and we usually work through those disagreements to a happy medium I’m usually surprised to find is better than the ideas either of us originally advocated.
Probably the biggest argument I had about how this hackathon should go (which wasn’t that big an argument) was with Arthur about Dinner. My initial position was that 250 halved burritos would be plenty. He started at 600 full burritos as a minimum. We eventually settled on about 550 halves I think, which turned out to be only about 20 or so halves too many.
I handled Breakfast and Arthur also handled lunch, and both of us got way too much food. Future organizers, take note! People, for reasons I can’t fathom, will leave your hackathon and not come back. The quantity of food you get for each of the meals should decay exponentially to compensate.
Another thing we screwed up slightly here is that we didn’t really pay attention to beverages. We got plenty of Red Bull and Coffee, but don’t forget water! We got 30 bottles or so — for 300 hackers. Some of the burritos were spicy, and we found ourselves in the uncomfortable position of having to tell people to line up at the single water fountain to cope with it.
Thankfully, by this point, the hackathon was well underway.
Step #12: Surprise and delight hackers to GET THEM MOVING.
Yes, they are. Dart Launchers. Some 200 of them. And students, also about 200 of those, at about 1:30am on a saturday morning. Just doing their thing.
Oftentimes, hackathons don’t force people to get up and move, even though that’s totally essential to their general health and wellbeing over those 24 hours, and to their hacking. Alex Gould, a seasoned hacker while still being a sophomore, decided we could do better, and got us these little hand-powered launchers, and they may have been the biggest hit of the whole thing.
Step #13: Give your hackers a chance to sleep.
Despite distributing pillows at 3am, we didn’t really account for the fact that hackers would need to sleep. Complicating matters was the fact that we had been told that we weren’t allowed to sleep in the building.
But, looking back, I wish I had told hackers around the time we distributed pillows to go home if they weren’t trying to win, get some rest, and come back in the morning. My least favorite part of hackathons is the 24-hour nature of them, the fact they hurt. Sleep is how the brain rids itself of toxins. Why sacrifice it?
Step #14: Think hard about what award scheme makes the most sense, and give them out fairly. A lot hinges on this!
A little after lunch, the hackathon comes to a close and we ask people to go to their assigned tables to present their projects, science fair style. Organizers and sponsors start walking around with clipboards.
For the organizers, our “hack” was the hackathon. The project we worked on during those 20 hours of hacking was making the hackathon as good as it could be for everyone else. Unlike hackers’ projects which they shepherded along throughout the night and got constant feedback from in the form of segfaults and strange CSS bugs, we couldn’t really tell whether anyone was having a great time. People seemed to be enjoying it alright. For those hackers who were around at 1:30am, we had a blast right there with them. But we couldn’t really tell whether any of this was worth it until we put our judging hats on and walked through the science fair. And then…
Oh My God. The projects were phenomenal. They totally blew us away. None of us were quite expecting how magical all of your hacks put together would be. We went nuts. The organizers room became a permanent fiesta.
We had initially wanted 5–8 finalists, but with the quality of the hacks, we ended up having to bump that to 10. After those presentations, the organizers and sponsors converged, and we voted for each of the prizes, and then rushed back to present those winners.
I’ll be the first to say we could have done awards better. I think that this aspect of the hackathon is one we didn’t do as much planning for, because just getting everyone to the hackathon, and making sure everyone had everything they needed seemed like a much higher priority at the time — if we didn’t get those done, there would hardly be an awards ceremony. But I really think we should have spent more time thinking about how we would review projects, had more time to deliberate about which ones would move forward, and spent more time deciding on what would be most important to us to declare a winner.
Reading notes like this one really hurt, because of how much work we put into this hackathon, I hate to think that anyone had a bad experience.
Dear Richard,I'm curious what factors played into the decision for the TripAdvisor prize. In years past, hackathons were a means for showcasing creativity and capacity to assemble complex programs in a short period of time. I feel the app that won the prize did not showcase these qualities, and I feel that our app (RoadTripAdvisor) was never really under consideration for this prize.The app that won, as far as I can tell, queried the TripAdvisor API once for a set of locations, allowed the user to select a subset of those locations, and then queried the Google Maps API once to generate directions to those locations.I worked with both of these API's as well, but I feel our application, which plotted optimal attractions, hotels, and dinner locations along a road trip route, made much more creative and extensive use of these API's. The winning app felt as though it had reached a near-final form, whereas we demonstrated significant opportunities to expand our application, which I feel is characteristic of a creative and complex project.What's most frustrating is that no TripAdvisor representative ever glanced at our project. You took notes on our application, and I appreciate that, but the fact that only one truly TripAdvisor-oriented application was able to present makes me feel as though we never had a chance. If we had presented, the representative could have made a real choice between more than one option.Please let me know what factors went into this decision. I want to make sure something like this doesn't happen again in the future, because even if the representative had chosen that app over ours, it would have at least brought comfort to know our names were in the hat. I understand that hackathons become more difficult to run as numbers grow, but I don't feel the situation was handled well, and I feel cheated out of the opportunity to be recognized for 24 hours of hard work. I hope nobody at a Tufts hackathon feels completely brushed aside in this way moving forward.
Thankfully, we managed to work with RoadTripAdvisor to a point of understanding, and I think we were all better for it. Take heed, future organizers! All the work culminates at the end, with judging. This is not a part to take lightly. This can make or break your hackathon, so do it right. I’m pleased to say that this was only one of two complaints we received, and we dealt with both elegantly. The vast majority of our feedback runs like:
Thank you so infinitely much CSX people who worked their asses off to make this event absolutely perfect. We all saw how hard you worked to stack this event up with sponsors, an amazing space, delicious food, a supportive, welcoming environment, assistance to people trying new things, ridiculous nerf-projectile catharsis, crisis management, and careful consideration in judging.Also, a gigantic thank you to all the former Jumbos who just up and decided to come, stay up all night, and help out just for the sake of it. It was amazing.I happened into taking a CS class almost entirely by accident, but quickly decided to become a major not just because I was interested by the material but the uncanny sense of community I felt with my Halligan brethren, and every time I go to one of these CSX events (specifically the Polyhack) my interest in the subject and sense of having a place here in the Tufts CS community is re-affirmed. And I know I speak for everyone when I say that.So thanks guys!
Step #15: Clean up everything. Everything. The slightest thing can screw everything up.
Upon arriving at the CLIC a couple hours before the event started, we met with Lorin Polidora who oversees the CLIC, just to sync up. As we started to move things to the fourth floor in the elevator, Roger Tobin, a physics professor walked down the stairs and just began yelling at her.
You know how sometimes, you see people yelling in public and it’s just really uncomfortable? That’s basically what this was. Lorin explained that the public spaces in the building were indeed public, that we were responsible Tufts students, and that this event was entirely legitimate. But he wouldn’t stop. He was incensed that the building and HIS KITCHENS could be accessed by anyone else than he and his fellow faculty members. The reason he was so sensitive about it is because Physics is one of the more neglected departments at Tufts, and once they were finally given a fraction of a shiny new building, they were not willing to share it.
So we had to prove ourselves, to keep the space as clean as possible. Once the hackathon was over, the 20 or so organizers spent some 4 hours cleaning, and we also had Tufts janitors come and clean up the space afterwards as well.
But it wasn’t enough. We didn’t erase all the board on all the floors, and one of the hackers had chosen to write a joke from the show Silicon Valley on one of the boards, which included the word “motherf***”. The work order we put in was only for the 4th floor , so Tufts’ janitors didn’t pass through the 2nd and 3rd floors. After what felt like a heroic cleaning effort, we learned we hadn’t done enough.
We were forbidden from ever using the CLIC space again. Lorin had clearly received too many yellings from grumpy physics faculty, and told us that hackathons would not be allowed in the space again. But I think they will.
Once we had the front page of the Tufts Daily, and the event was reported a massive success, I think everyone cooled off a little and saw each other’s perspectives.
Thanks to the whole team of organizers for working so hard on making this even possible, and thanks to our sponsors for also making this event possible.
And if you’re organizing a hackathon, be it 2016’s Polyhack or anything else, feel free to reach out to me at hello at alexlenail.me for any advice of any sort.
