Are Hackathons Overrated? Part 3
The Results
The biggest piece of feedback from volunteers was that there was not enough time to code. Point taken: volunteers only had nine total hours over the course of three days for code and design time. I may have been a bit overzealous with the number of speakers I solicited (including a comedian). One volunteer commented he did not understand why a Denver politician showed up. Let me explain.
Kelly Brough — one of the two Denver mayoral race runoff candidates — graciously accepted our invitation to speak at the hackathon. However, her address took an unexpected turn as she called attention to the dishearteningly low voter turnout among millennials, the vast majority of volunteers. She is not wrong. Look, I am not making excuses for my generation. People should vote. But millennials do not have what generations before us had: faith in our institutions. Like government. College. Church. Just to name a few big ones. I wanted the hackathon to demonstrate how much the institutions in our community need our technical expertise. Having a local politician share her perspective aligned with this overarching theme.
I hoped that if the first hackathon was a success it would continue as an annual event, becoming an institution itself. The weekend was filled with energy, in-real-life interactions, and so many snacks. Let me paint you a picture.
Kudos
What did we actually build?
A lot of the code written at hackathons never get used after volunteers go home. Was our hackathon any different?
Live, Tangible Creations
- Embedded annual reports and streamlined documentation for a Wordpress website
- Efficient “Contact Us” form with appointment scheduling
- Revived and enhanced an existing Rails application
- Cost evaluation of a custom peer-to-peer texting application
Unreleased, Open Source Creations
- Designed user flows and wireframes for 3 custom applications
- Wrote a Python script for Google Drive organization
- Built a prototype of an analytic application for tracking foodborne illness outbreak costs
- Built a prototype of a volunteer tracking application using Rails, React and the Twilio API
Intangible Creations
- Forged foundational partnerships with 4 non-profits. All stated they would participate in the another hackathon.
- Built a volunteer community. All 21 survey respondents said they would participate in another hackathon.
- Created a mentoring and networking space
- Empowered non-profits through technical project scoping. All rated the scoping process as the most valuable outcome of the hackathon.
While our hackathon may not have completely dispelled the stereotype that hackathon code goes unused, our volunteers made several contributions which are still live on our non-profit partners’ websites today.
I suspect this hackathon delivered more value to the volunteers than to the non-profits. Writing code, creating designs, learning new skills, working under pressure, building camaraderie… these are all intangible benefits the volunteers reaped. Ideally, non-profits would gain just as much. To balance the scale, here are a few things I would do differently:
What to improve
Project scoping was the most challenging part. Teams spent too much time determining achievable goals. Next time, I would not shoulder the full responsibility of project scoping and involve project leads earlier. Ideally at least four weeks prior to the event. This would create greater ownership and accountability, increasing the likelihood that something valuable will delivered to the stakeholder.
Project scoping was difficult for another reason: many of our non-profit stakeholders were not experts in software development, and I was not an expert in their business model. Bridging this gap was tricky. I approached them with the pitch: we can build software to automate something your staff does or organize your data better. For instance, one of them sought a peer-to-peer texting application to monitor volunteer engagement, aiming to replace a paid app called Impactive. Our team conducted thorough research, including a build vs. buy comparison, and subsequently created a prototype. The outcome was not entirely surprising; it was more cost-effective for the non-profit to continue using Impactive rather than relying on volunteer-maintained software. This experience led me to the realization that, from the outset, we should have brainstormed more ideas on how the hackathon could help these organizations.
This prompts the question — is volunteer-maintained software ever an appropriate solution? On one hand, software by default is fragile, nuanced, and requires maintenance. However, giving non-profits more control over their technology is a game-changer. One way to make this achievable would be to institutionalize hackathons. They need to be ongoing with dedicated phases for identifying, scoping, building, and maintaining projects. This is how the Ruby for Good model works. Events are annual and volunteers can continue to hack on projects in the off-season because they are entirely open-source.
Software development also requires iteration in order to be successful. For example, one of the non-profits wanted a way to automate sorting thousands of their documents in the company Google Drive and specify the correct level of authorization for different staff members. Our team built a Python script using a lexicon which was quite impressive. However, when they fed their documents to the script it did not sort properly. The hackathon provided a great start but the team needed more time to iterate to a working solution.
Finally, one more improvement I would make would be to push harder for volunteers to use ChatGPT. I bought a ChatGPT 4 subscription but it wasn’t fully utilized by volunteers. I firmly believe using this new technology would enhance the efficiency of every aspect of the hackathon, encompassing project scoping, development, design, summarization, and project handoffs.
What went well
Was it all worth it? I keep going back to this question to justify my own valuable time and energy spent organizing. After gathering feedback and measuring outcomes, I have a few takeaways.
Social capital is more important than ever right now. Volunteer feedback showed this was the best outcome: I asked participants what they liked most about the hackathon and 80% percent said the people and connections they made.
Technology is increasingly becoming a remote industry. A chance to work in-person with colleagues is a tradeoff many are making to gain flexibility yet at the cost of shared physical experiences. Look, we are animals and Zoom calls simply cannot replace being in the same room with someone where you can smell them and communicate with body language. Not only are in-person experiences fulfilling on a personal level but indispensable in your career. How else will you stand out in a sea of smell-less, 2D resumes in your job hunt?
Additionally, non-profit stakeholders got the chance to have in-person interactions with volunteers. This created a sense of connection for them too and the chance to engage with technical experts, a resource that is typically outsourced from non-profit staff.
A hackathon also provides a setting to create something meaningful under pressure. I am asked to do this everyday in my dev job at a startup — my team is asked to build a bicycle and we do not have enough time to complete all our tickets before the deadline, so what do we do? Build a unicycle! The hackathon is a perfect incubator to learn how to cut and revise scope. After all, a hackathon is a hack. It requires creativity to figure out the shortcuts to get something done.
This skill is especially valuable now because of the massive tech layoffs. Employers like to see work experience for real stakeholders on a resume, not just personal projects.
I am not a fan of the hackathon model where project ideas are driven by the volunteers and not outside stakeholders. The code that gets written at these events stays relevant only until the prizes are given out. It is already a common feeling of futility among my peers that we spend much of our time writing code that is so ephemeral. It’s not like we are building concrete bridges that will last decades. We are building code in cyberspace that might have a shelf-life of three years before it’s changed. That is, if our code even makes it to production. I think it is important for hackathons to create as much lasting value as possible.
One participant summed it up best: “I found it interesting that I was able to get so involved with the team and project that I started today feeling like I was returning from something big, even though the event only really took place over 2 days.”
I think this person is getting as that overwhelming sense of purpose and importance that naturally comes when you work alongside others towards a common goal. As they point out, it doesn’t take that much time to generate this feeling. Another word for this? Community. That is exactly what I spent all my time trying to create. To me, that is the point of a hackathon.
On the flip side, just like software, that sense of community can also be ephemeral. That is why it is so important to keep hackathons going! While I was proud of myself for spearheading an idea and making it come to life, organizing a hackathon year after year is not sustainable for one person. I need more help. This was the final lesson I learned: community is necessary for creating something bigger than yourself. Something that will last. Something that people keep coming back to because they have faith in it. A well-run institution.
