Surviving My First Hackathon

I recently attended my very first hackathon. I had no clue what to expect and I did not even have an official team. I just knew that I wanted to show up and do the thing that I had been avoiding for some time. I encourage you to read my blog post regarding Imposter Syndrome and find out which Imposter often holds me hostage.

The FirstNet Developer Program hosted their first ever “FirstNet Public Safety Hackathon” in San Francisco, CA at Covo. Developers in attendance were asked to build an app for assisting first responders in the field. The app would help firefighters, law enforcement, and EMS (emergency medical services) teams.

Image via FirstNet

After an amazing panel of veteran First Responders spoke, we were presented with recommended use cases and suggested prompts for each discipline: Firefighters, Police, and EMS. My team saw an overall theme in the challenges facing each discipline: comprehensive incident awareness, automatic responder tracking, and on-scene witness logs.

After hearing about the disciplines, we heard pitches by sponsors about the tools recommended for this hackathon. Each team gave an overview of their APIs. We heard some amazing talks from IBM Watson, Esri, Samsung, and FirstNet.

Image via FirstNet

How did I survive?

  1. Find a team — The hackathon allowed you to request teammates on Slack or you could pitch your idea on the day of the event and request teammates live. Instead, I decided to walk around and ask smiling faces if they needed a team. I felt individual interactions were a better way of getting a feel if myself and that particular person were in alignment with one another.
  2. Get to know teammates — We exchanged individual specialties and background information. Our team consisted of two frontend engineers and two backend engineers. We were a blended crew that took the either the college or tech bootcamp route to become engineers. This was the first hackathon for a couple of us participated in and the second one for the rest. Ironically enough our team of four was formed by two teams of pairs and each pair knew each other prior to attendance.
  3. Express intentions — I explained to my team that I was here to learn and help in whatever way that I could. Although the goal is to “win,” I was also there to grow and develop the meta skill of getting involved with a new project, with new team members, while working with unfamiliar programming languages.
  4. Refrain from coding right away — Create project specs, wireframes, and an overall plan! This will help keep you on track while hacking in a short period of time.
  5. Stay open — Allow new ideas, inspirations, and suggestions to flow but remain in alignment with your team goal. On the first evening of the hackathon we decided on a completely different app idea. As we began to implement the idea, we started to ask each other a ton of questions and giving various examples of issues the first responders may encounter by using our app. We then went thru various iterations hypothetically and decided on a final MVP.
  6. Read tons of documentation — I was exposed to Java, Android Studio, Go, and the APIs mentioned above from IBM Watson and Esri.
  7. Utilize the Developer Relations (DevRel) teams in attendance — Ask questions and get unblocked, quickly. Each DevRel team is there to support you and cheer you on. You will later find out why I wish I would have reached out to each team sooner. See section, “What will I do differently next time?” bullet 3.
  8. Take breaks — Self-care is everything! Having a fresh set of eyes will allow for more quality contribution to your team. Go for a walk, step away from your computer, and relax for a moment. Luckily you are working as a team, so while you are away, your teammates will continue to hack. Alternating breaks will help a ton!

Of course, there was more to the hackathon than just the process… we actually built an app! And as you can imagine, “staying open” mean that we went through quite a few few iterations of ideas. We had an initial idea that was later intercepted by a veteran first responder with a MAJOR tip. Find out below how it all played out.

Scenario A: Initially we wanted to assist Firefighters. We started off with the example of someone seeing a fire. The witness would be able to report the fire, take a photo, report if they were safe, and then that information would be transferred to the responders dashboard. We wanted to also show how server the incident was based on the amount of reports that would roll in, however we quickly realized the amount of witnesses may vary per event but that does not mean it was any less sever.

Scenario B: Before we got ahead of ourselves, we checked in with the experts, the veteran first responders. We spoke to someone who was retired law enforcement, and he explained that while the reports are great, the first responders are actually only interested in new witness accounts. If someone were to call into 911 and report a burning car, all that is needed is that one call for the proper teams to arrive on scene.

However, new eyewitness information is more relevant when helping to put to pieces of the puzzle together regarding the who, what, when, where, why, and how’s of the situation.

Final MVP: So what did we decide? What direction did we end up going in? No spoiler alerts take place in this post BUT I will leave it to you to explore our lovely app and see the the raw code HERE.

Image via Team First Alert

What will I do differently next time?

  1. Prep — I wish I would have read more info on challenge prior to getting to the event. This would have allowed me more time to ponder on what project goal I was looking to accomplish.
  2. Team Diversity — Having more of a diverse team that included Product Managers, Project Managers, UI/UX designers, and etc. would have allowed for a more robust final product. Our team was approached by two UX designers but we were unsure as to how we would properly incorporate them into the team. The duo later went on to find a team and helped create an absolutely beautiful app with user flow as its number one priority. Looking back, I now see the importance of having a diverse team even when you are unsure how you will all flow together. It always works out in the end.
  3. Bug Timer — Being on a limited time crunch, asking for help (soon) is not only essential but critical to ship a minimum viable product. My partner and I spent around 4 hours attempting to resolve what turned out to be a pretty interesting bug regarding latitude and longitude conversion. We reach out to the DevRel team at Esri and received a solution after an hour of debugging. Although this solution did resolve our issues, it was too little too late. We’d spent valuable time debugging versus building and our time quickly ran out thereafter.

Takeaway: Show up! Go to the hackathon, bring your talents and positive attitude, and I can almost guarantee that it will be worth it :)

If anything in this article resonates with you, please show below with a comment or a round of applause — aka claps ;)