Learning to Code: My Story as a Galvanize Web Dev Student, (Series) Part Six

Learning to Code: My Story as a Galvanize Web Dev Student, (Series) Part Six

This is a series written by former Galvanize employee Dan Beerman on his experience as a Galvanize student in WDI Cohort g70. Read Dan’s first post in the series here.

 

A Tale of Two Hackathons

It was the best of times, it was the worst of times. It was the age of learning git workflow, it was the age of merge conflicts. Ok, ok, perhaps a bit melodramatic, but the g70 class has had two mandatory hackathons. These are built into our curriculum to encourage collaboration, teamwork, and creativity as well as another chance to practice public speaking and presentation skills.

Wondering what the heck’s a hackathon? Hackathons are time-boxed product building challenges. For example, the challenge might require teams to use Weather Underground API to build an app. Teams may make a kite flying weather app, an outfit suggestion app, or even a severe weather alert system. The ideas range from fun to serious – and winning depends on the pitch.

Hackathons are not just for developers. Turning out a MVP (Minimum Viable Product) in a few hours requires a balanced skillset: design, marketing, business thinking, project management, engineering chops, etc. No matter your background, these events can be a great way to have fun networking, practicing and honing your skills. If you’re interested in challenging yourself and enjoy creative challenges there’s a hackathon out there for you.

So how did the hackathons go? In short: they were incredible. While my team didn’t win either event, each team I was on learned to work collaboratively, honed project management skills, and truly tested ourselves. There’s no substitute for trial-by-fire: sitting down to a blank screen and ticking clock with no clear path forward. Hackathons are great for forcing a team to come together.

Each hackathon was distinctly different, I’ll breakdown each event below:

Hackathon 1: Build a Light Web App

The challenge given by the instructors was that teams would have a span from 10am to 4pm to put together a light web application based on a theme. The theme would be revealed at 10am. Creating a light application just means building a front end, static server without any databases. Code has to be deployed through services like Heroku and/or Firebase. When 10am hit the instructors announced the prompt would be to create an app for the domain name ‘where.com’ (or ware.com, wear.com, were.com, etc). Off to the races with my team: Brandon, Brian, and Carolyn.

Brainstorming: Blue Sky

Carolyn has valuable experience in an agile work environment. She had us start with a brainstorming exercise calling Blue Sky: 15 minutes, no bad ideas, all written on a dry-erase board. We hit on wearable tech, location/travel sites, hardware, tupperware, and all the other kinds of where/ware/wear things you could think of. After discussing the good and the… less good, we landed on our favorite idea.

Hacking it Together: W’HERE

We landed on w’here, which is more like ‘we’re here’. The app that lets you announce your arrival to any location. When you show up to a place, e.g. a bar, a conference, a family event, etc,  you want intro music and video playing for you! We integrated Youtube’s API, an express/node server, javascript, HTML & CSS. Users can also submit their own situation, song and video in case our list wasn’t comprehensive enough.

If I were to move forward with this app I’d love to see it as an Amazon Alexa skill or something similar. That way when I show up to my friend’s house instead of using a doorbell, his speakers play my theme song.

Reflections on Hackathon 1

Sound totally nuts? Well, we lost to a werewolf tracking app, so I was pretty happy with our project. More importantly, my team and I learned to work together more effectively. We pinpointed some weaknesses and were able to help each other. Also, one of the most valuable lessons was that communication is key. When presenting technology the quality of the pitch has almost nothing to do with the tech and everything to do with communication and style.

Hackathon 2: MISSILE-ALERT.FUN

The second hackathon was protested by the class; we wanted to have more time to work. We weren’t excited to lose a full day of instruction, but we compromised on a half-day hackathon. Starting at 1:30pm, teams were given the prompt. This time, the idea was to create an app for ‘missile-alert.fun’ (this was right after the Hawaii missile scare). My team this time was Jay, Mike, Bryan Long, and Patrick. Another group with balanced skills and interests.

No hesitation: Who’s Got Next

Our team quickly decided our product would be a theatrical demo of a Ping Pong queue and a scoreboard app called Who’s Got Next. Why? There’s only one ping pong table at Galvanize and students and members could use a way to hold their spots in line.

What did this have to do with Missle-Alert.Fun? Basically, nothing. But we did build a game reservation app in two hours and had fun making something as a team. We utilized some advanced version control workflows, deployed on Heroku and Firebase, express/node server, javascript, HTML & CSS. We stuck with the familiar with only 2 hours to put the pieces together.

Reflections on Hackathon 2

The winner this time was an app for planning your recreational activities during an impending disaster. Again, a hackathon is really about practicing project management, tech presentations, and teamwork. This round, my major takeaway was that a project management strategy can cut build time in half. This app was more complex, but our team was able to contribute more effectively because we had most skills than the first hackathon.

Presentation Presentation Presentation

Comparing the two experiences, more time doesn’t necessarily mean more quality. During a hackathon anything can go wrong. Code can get broken when one dev edits another’s work. Also, I ran into an incompatibility issue during the first hackathon that cost me over an hour to fix. During both competitions, most of the student teams experienced issues with git version control.

Additionally, I have to reiterate that clear communication and style seemed to be the common factor for the winning teams. Showing an audience your enthusiasm and excitement for an idea may be the ingredient needed to encourage them to try it out.

Finally…

If you had told me 4 months ago that I would be creating a functioning app from scratch with a team in just a few hours I would have told you that you were crazy. In general, these exercises were excellent for showing me how much I’ve learned and demonstrating that coding alone isn’t what Galvanize or tech is about. The team, the process, architecture, everything is a process. As always, I’m learning a lot and the experiences continue to be invaluable.