Lessons Learned from EA Hackathon following EAGxBerkeley

The purpose of this post is to provide a debrief on the outcomes of the Hackathon held on 12/5/22 following EAGxBerkeley.  

Goals:  

• Provide an engaging activity as part of the participant-driven events surrounding the conference
• Promote skill building for software engineers and aspiring developers
• Create an open and welcoming space for non-software engineers to engage in project work and coworking 
• Facilitate opportunities for networking, mentorship, and general community building for EA Software Engineers
• Collect feedback and determine whether this kind of event would be worth holding again

What went well:

• Hosting a Software Engineering meetup and Hackathon planning event during the conference helped boost awareness, solidified people's intentions to attend, and helped attendees hit the ground running
• We also gave out hard copy flyers at Berkeley coworking spaces and during the conference which I think helped with awareness and stickiness
• More attendees than expected!  We were anticipating 25-30, but we got 45
• Excellent support from conference organizers and venue staff.  We brought / borrowed power strips, extension cables, whiteboards, and large writing pads that felt pretty essential throughout the day
• Out of a possible score of 5, the average respondent to the feedback survey (n=8) rated overall experience as 4.125.  Impact was rated as 3.75.  Collaboration was rated as 4.125. Learnings were rated as 3.5.  Fun was rated as 4.375
• Google Photos album to collect photos and videos from the event (and create a sense of FOMO for everyone who couldn't make it)

What went poorly:

• Wifi at the venue was quite bad.  In the future, we would mitigate this with setting up mobile hotspots for the day, or we could find a different venue
• We should have swapped the order of the dev environment and git learning sessions.  Also, given the wifi situation, we should have told new devs to download VSCode in advance of the event
• Lack of specificity in project pitches. We should have asked pitches to include the tech stack and relative level of difficulty of various roles
• Low response rate to feedback survey.  We should have dedicated the time and requested that participants fill out the form before we ended the event

Worth experimenting with in the future:

• Explore hosting a hackathon on Thursday or Friday before the conference starts
• Hackathon on a specific priority area could have more impact by bringing together people with a dedicated focus
• Consider hosting a more formal event with an application, a presentation of results, and a judging component
• Bay Area organizers should consider hosting more events in the Community Spaces of Sports Basements.  They're free and were great to work with
• Use reoccurring office hours to encourage continued project

Resources:

• Forms:  Expression of Interest, Sign-In, Feedback — if you want to replicate these Google Forms, email [email protected] and I'll add you as a contributor so you can make a copy of each one
• Event announcement:  Forum post, Facebook event, flyers
• Learning sessions:  Git workshop, Setting up your Dev Environment, Intro to Frontend, HTTP and CDNs

Outcomes:

• Give Calc tool — a Streamlit app that provides advice on how much to donate for people interested in lowering their net income by a percentage or an absolute amount. It's based on the PolicyEngine project, which is an open-source tool for exploring the effects of tax and benefit policies.
• Contributions to open source projects — numpy, pytest, shed
• Updates to landing page for Impact Markets — a three sided marketplace that aims to eliminate externalities for funding impactful projects

Impactfulness:  we set the bar intentionally low for output from the event, which lasted from 10am - 5pm due to constraints of the venue.  We figured seven hours would be enough time to make some progress on simple features, but nothing earth shattering, particularly once setup, lunch, and breakdown time is factored in.  We hope that EA community office hours will spur continued project work

Tractability:  because the Hackathon was pretty unstructured, the main cost to set it up was the time of the organizing team and the cost of lunch.  Now that the organizing work has been put into place once, it would be relatively low lift to reuse this playbook when hosting the next event

Neglectedness:  the event aimed to serve what we hypothesized was an unmet demand for fun, quasi-structured activities around the time of the conference.  This  fact that 45 people showed up and no one reported having a bad time (i.e., no feedback respondent rated their overall experience as less than 3 out of 5) seems to validate the experiment

Summary:

Hosting a Hackathon seems worthwhile.  Attendance was high, feedback was positive, some skill building took place, and at least one person reported feeling more engaged with EA as a result of the event. 

We have identified some things that we think we did well, along with many opportunities for improvement.  It would be straightforward to do this again as a community building exercise.  With a more structured approach (such as focusing on a specific cause area and asking applicants to apply), we could potentially generate more impactful outcomes.

More EAG(x) might consider incorporating this activity into the events before or following the conference.  Furthermore, city groups might be interested in adding a hackathon to their calendar of event programming.