Takeaways from My First Hackathon

This week, I participated in my very first hackathon (cue applause). I guess you could call my entire time spent at coding bootcamp one huge hackathon, but they didn’t give us breakfast tacos and muffins so it doesn’t count. #firstworldproblems

A brilliant coworker of mine brainstormed the project I ended up working on a month ago — it wasn’t obvious which rows were included and excluded in a table that gives our customers important data. Here’s what I mean:

Data changed to protect my career and, because kittens.

At first glance, you might not even notice the color change. Sadly, little Reginald was excluded from the data that gets pulled from this table. To make it more obvious which rows were actually included in the data we were giving them, my coworker and I came up with a few ideas.

Grey out little Reggie to show his sad, excluded existence
Give Reggie a big red dot to mark his exclusion
Make Reggie stand out even MORE by sorting him to the top of the page. Poor little guy.

Overall, I’m ridiculously happy with how my project turned out. There are a few things I would tell my future self, both for my sanity and to make things run more smoothly.

  1. Be prepared. Our hackathons are 1 1/2 days long from kickoff to presentations. My mom always told me to be prepared, but who actually listens until they spend half the day trying to spin up their local environment because they haven’t used it in four months?
  2. Put the “hack” in hackathon. This day and a half time constraint made my perfectionism cringe THE ENTIRE TIME. I reused a method to add some functionality in a different area than it was meant to be used, but by misusing that method, I was able to think through how to write a method that correctly did what I was trying to do. I even had time to refactor it. Quiet down, perfectionism. You’re not wanted for these 1 1/2 days.
  3. There’s more than one way to solve a problem. I brainstormed several different mockups because my changes would be customer facing, if accepted. Some ideas work better depending on the use case, and it’s nice to have different approaches.
  4. Branch out. My project was all UI — I used some Ruby (in an HTML file), Sass, and a little bit of jQuery. I hadn’t touched HTML, Sass, and especially not jQuery in months. I forgot how much I liked working with them respectively, but also how much I LOVE Ruby. Getting into languages and projects other than what you’re currently working on can either serve to reinforce that you are where you’re supposed to be, or point you in a new direction.
  5. Sometimes the smallest changes make the biggest impact. I worked on fixing an issue that wasn’t *critical* to a good customer experience, but it is something that people have asked for and will notice once it gets shipped. A good project doesn’t have to be life altering or a huge undertaking. Attention to detail is what really makes a product stand out, whether customers realize it or not.
Here’s the first picture of a kitten that popped up when I googled “kitten.” I’ve named him Reggie. Don’t let him down.
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.