Hackathons are a lot of fun. Working hard to get a piece of software done in a short period of time and pumping out some incredible results … it’s really a great experience. Or so I’m told. This weekend I had my first hackathon … and it was a bit of a mess. It started off pretty decent. I had an idea, I broke it up into “stages”, and got to work on my MVP. I actually got my MVP working pretty quickly … except that I was trying to use some javascript that I discovered isn’t universally supported. I decided to put that problem aside for a moment and work on using a new API … except that I was having trouble querying the API (apparently ‘fetch’ and I don’t get along). Once I was able to query the API (yay axios!), it kept telling me that I was unauthorized (in the API’s defense, I was using the wrong API key … so that was a me error, not an API error). I was having issues trying to use ‘forEach’ in my React app (I probably should have known to just use map). I had trouble figuring out OAuth and a new API … and once I finally got it working as I wanted and deployed it, I couldn’t get it working on my deployed site (I’m still dealing with that issue). Basically … this hackathon has been a mess. As much as I hate that my app is not exactly what I was hoping it would be, I learned a lot from this hackathon. Here are some of the lessons that I will be taking with me as I build my career as a developer: . At the beginning of this project, I made a list of things that I wanted my app to be able to do. My plan was to start with the most basic feature, deploy that, and then start adding features. This was a great idea — if I had just tried to do everything before deploying, I would have been frustrated. Working in small pieces allowed me to deploy as soon as something was ready, and if one of my planned features didn’t work as planned (see below), I just deployed the app without that feature. Work in small pieces In every situation, there will be someone available to help you … whether that’s a senior developer at your company, a teaching fellow at your coding bootcamp, or the helpful people on Stack Overflow. Some struggle can be productive, but if you just can’t get something right, don’t waste your time — ask for help. Without the help of one of my teaching fellows, I might not have thought to use axios to query the API I was working with, and if I had continued to struggle with trying to use fetch, I might not have been able to implement the feature that was the core of my app. Ask for help. . During this hackathon, a lot of things went wrong for me. Some were easy to debug (like using the wrong API key), but others were more difficult to figure out (and there’s one feature that I just haven’t been able to implement because it breaks when I try to deploy it). While at first these issues bothered me, I quickly learned that I’ll never get anything done if I keep letting failure get me down. When things went wrong, I quickly learned that I had to just accept it and move on. Things will go wrong . Some features will be harder to implement than others. If something is harder than it seems, decide if that’s a core feature or if you can put it aside and try to come back to it later. Don’t try to do everything at once — especially during a hackathon, where time is short. Knowing that you can’t do everything is essential to keeping your sanity while working on an app. Manage your expectations While my hackathon app wasn’t exactly what I was hoping, I am happy that I produced something — and learned a lot in the process. I’d still call this hackathon a success, and I’m definitely going to keep working on this app.
