Tips From My First Hackathon
Last weekend I had the amazing opportunity to be a part of a hackathon hosted to demonstrate a new full-stack framework. Myself and three friends had from Friday night until Sunday night to build a web application with the framework, with literally no other requirements. As long as we use TriFrame and had something to present Sunday night, we could build whatever we want.
To be clear, this is not always the case with hackathons. You may be required to use a specific language or solve a specific problem. But in this blog, I will be writing about the experience of myself and my teammates and mentioning a few things we did right and a few things we did wrong. Obviously every hackathon is different, but I hope you can take something from my experience and keep it in mind at your next hackathon.
Preparation
Our Success
The thing that helped our team the most was our preparation. Right after the kick-off meeting, our group got together and started hashing out ideas. Luckily, we quickly agreed on an idea, but it was what happened next that set us up for a productive weekend. Once we agreed on an idea, we wrote out the user story, wrote the models we would need and their relationships, and outlined some stretch goals. By planning out most of our project in advance, we spent less time during the coding process worrying about what components and functionality should exist.
Another great way we prepared was making a trello board. Trello is a list making web application used for project management. In trello, we made categories for In Progress, Completed, Road Blocks, To Do, and Stretch Goals to keep track of where we were in our development process. In addition to the categories, each card can be assigned a user who is responsible to complete that deliverable. Below is a screenshot of our trello board demonstrating a bit of the workflow we ran through.
Where We Could Have Done Better
Although we spent a lot of time planning and running through our ideas and process, I believe we still could have done better. One roadblock we ran into while building our project was deciding what color scheme to use to style our project. Although saving the styling for last allowed us to function on the functionality of our application, I believe if we had planned perhaps a color scheme and built a quick wireframe we could have saved some time towards the end of development.
Time Management
Our Success
As you can imagine with only a weekend to complete a project, time management was an important part of meeting our goals. For the most part, we worked many hours during each day. Friday night we stayed up until around midnight, Saturday we worked from 9:00am until midnight, and Sunday we working from around 9:00am until the presentation began! We took brakes throughout the day for lunch, dinner, and to rest our eyes. Overall, it felt like we spent 90% of our waking hours working on the project. Though this it was good to spend so much time working, there were a few disadvantages to our ‘head-first’ approach to this project.
Where We Could Have Done Better
I believe, and I think my teammates would agree, that we should have scheduled more consistent breaks. Though we did take breaks, for the most part we only took them when we were at our brains limit and simply couldn’t look at a screen any longer. Scheduled breaks, even for 5 to 10 minutes to stretch your legs, can make a huge difference and prevent fatigue. I highly recommend you discuss a plan for scheduling breaks for you group. Also remember you are doing this for fun, so if it starts to become a headache there is nothing wrong with taking a walk around the block, doing some push ups, or just taking a mental break when you need it.
Development
Our Success
The last thing I want to talk about is the actual development and coding process. Our approach at this process was mainly to work together as a team, and have one person ‘drive’ while the rest of us ‘navigate’ and do research. If you have not done any pair programming before, I highly recommend you try to get some under your belt just to get used to the experience. If you are a programmer who usually works alone, it can be unusual and even uncomfortable to have someone telling you what to do. However, it is a great way to work together, catch errors, and keep everyone on the same page.
Since all of our team members came from Flatiron School, we had a lot of experience in pair programming. This allowed us to navigate through tough issues smoothly and efficiently by working together. Sometimes one of us would be learning how to implement a new technology while the other three were setting up the application to include it.
Where We Could Have Done Better
Although we made good progress working together as a team of four, there were some points where it felt like four was too many to work on one deliverable. Perhaps once or twice, we split up into groups of two to tackle two problems at once. In my humble opinion, I felt this was a much more efficient way to cover as much ground as possible. The ‘Scooby-Doo’ effect, if you will. We would then reconvene to discuss what we had accomplished or work out issues we couldn’t solve.
This could have setbacks of its own, of course. For example, each team, or even each individual member, working on a different functionality should make sure that 1. Their work does not interfere with the rest of the team’s work, and 2. They have clear instructions on what to do. I recommend anyone going into their first hackathon make it a point to at least suggest to your team that you try to split into smaller groups or individuals to accomplish multiple tasks at once.
GitHub
I would be remiss if I did not include some advice on version control. We used GitHub as our version control system. We each created our own branches, and merged them as a group to ensure everyone understood the new features. This could have been done a number of different ways, for example we could have built branches based on features. What is important is that everyone is on the same page with the version control follows the same process.
We faced some issues working with GitHub that slowed our work flow down a little bit. I recommend to anyone going into a hackathon brush-up on your GitHub collaboration skills and make sure you understand exactly how you want to manage your project and its branches.
Enjoy It
Over all the best advice I can give is to enjoy your hackathon. Although we were all a little sleep deprived and maybe our eyes were a little red from staring at the screens, our group had a great time working together and building an application. We even came in second place and got to deploy our app on Heroku! If you follow some of these tips, and find a group of people you enjoy working with, your hackathon experience will be a blast. Happy coding!
Aside:
We will be re-deploying our application in the future I will share it on this blog and on my personal website.
Huge thank you to Faizah, Francisco, and Melike for allowing me to work with you. You are all so smart and creative and I can’t wait to work together again.
References:
