Learning from My Hackaton Mistakes

Disclaimer: I have won some and lost some

I won something in my first three hackathons, and then I did not win a thing in the next two hackathons. These losses made me deeply thinking on why I lost. We made a very decent app, functional, decent UI, and solve a real problem, but it did not even made the preliminary round in those losses. So here are my opinions on why we losses:

1. Think Big but Failed to Make Other Understand the Idea
A hack is an innovation. You made something possible when it’s not even possible before. And when you think big and have a great idea, oftentimes it’s not easily understandable by people. So the problem is how we deliver the idea. Role playing is a good way to do this, but choosing the right words and the right sentence is the key. One of the main reasons I lost was I could have done better in delivering these ideas IMO.

2. Fancy but Not Clear Design
Great UI is a boost in judging, but we need to remember to design it so people could easily understand. Hackathons have a strict time limit, vary from 90 seconds to five minutes, so we need to design the app as clearly as possible. I mean, people and the judge would only see the app in a glimpse, so a good and clear design will help them understand what your app does in those limited time. In those losses I think our app design is quite good, but hardly understandable by people at the first look.

3. Do Not Use an API Just for the Sake of Using the API
In hackathons, there might be multiple APIs and challenges, and to boost the percentage of winning, we might think we should use more API so we might apply for more challenges. Well, it is not a wrong thinking. But we need to remind ourselves that the sponsors expect their API to be used in something extraordinary and fundamental. So make sure that we use those API to solve something fundamental, not an additional feature which is hardly needed by people. Once again, I have experienced this pitfall.

4. Preparation IS not the only KING
Better preparation results in better execution. This matters when you have very limited time in building an app. But this could be utterly useless compared to Big Ideas. So make sure you have a very Big Idea combined with a good preparation. Well, this is arguable since I have seen lesser ideas won, but better idea combined with good idea presenting will make the judge have no other choice to make you a winner. In every hackathons I always prepare and organize so it is feasible to finish the app. Mockups, database designs, API designs, Task Delegations, we always prepare for that. Heck, I even made my API cleaner and more robust along each hackathons. The thing is the judge don’t give a shit about that. Their main concern is your idea, how can you make an innovation to make life better.

Hope this post helps and feel free to discuss.


Why Basing Your Success Without Evaluating is Bad

You might have read this quote:

Success is a lousy teacher. It seduces smart people into thinking they can’t lose.
– Bill Gates

When you succeed on something, the first thing you feel is a joy. This joy could lead into arrogance or laziness. But when you failed, the first thing you feel should have been a disappointment. And when you are disappointed, the questions that should have popped up in your head are “why”, “what”, and “how”.

  • Why did you fail?
  • What went wrong and what should have been done?
  • And, How can you do better next time?

Well, a success is not a bad thing and we should aim for success actually. But when you succeeded something before, do not jump into conclusions on why you were successful. You might think that the reason you succeeded is “A”, but you should challenge that idea. Is “A” really the reason that you were successful before? You need to be careful in evaluating your success so that you could you use it to gain more success next time. In the end, failing itself is not really a bad thing, but failing and giving up without evaluating is the worst.