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:
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.
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.
- 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?
- 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.
- 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.
- 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.
- 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.