Hackathon: Mistakes
Hackathon — A competition where you are supposed to develop an application with a breathtaking idea — in a very short amount of time, usually 24 hours. For anyone who has developed a full application/system before, they immediately know that sacrifices must be made.
So far, I’ve competed in 5 national level hackathons and successfully won 2 of them. I won’t say that I’m an expert, I’m simply sharing my point of view, what mistakes I have made, and the lessons learned.
For some of you guys that have not competed in a hackathon, you might say that the idea of the competition itself is crazy.
“How you’re supposed to make a full blown application + pitching materials in 24 hours? That doesn’t make any sense!”
And I must say that I agree. It doesn’t make any sense if you want to build a production-ready application. But you are not required to build your application to that level. Hackathon competitions simply want you to prove that your idea is applicable. Therefore, you simply need to create a working proof of concept, some eye candy, and pitching materials (aka. something to boast about + a pinch of bullshit). And you can do this in 24 hours, granted that you have a good team.
“We should focus on the product! We could do anything else later.”
Well, not really. Every competition organizer has a reason why they made the competition. And your focus should be aligned with it. I’ve encountered somewhere the main focus of the competition is simply to brag about the competition itself, how the ideas produced sound cool. In short, in those kinds of competitions, you need to write as many buzzwords as possible. (and successfully implement some of them/be sneaky around it)
“We have a team full with developers, so we could complete the application”
Big nope, you should have a balanced team where there is someone who could do the pitching. The same goes for the composition of the developers, they can’t be all frontend, backend, or AI engineers. It would be nice if one or two of them have a specialty in more than one field because the team member count is very limited (3–5 people).
“You do your part, I’ll do mine. If you’ve not completed your part, it’s your fault and I don’t want to help any part of it”
Does it sound ridiculous? Well, believe it or not, I have encountered such cases. One of my team members is very good at a certain field, and he split that task with another person. The other person is limited in knowledge (because the underlying tech is chosen by the first person), yet somehow the first person doesn’t want to help the other. TLDR, the first person slept throughout the night, when the second one didn’t even have a blink of rest. Make sure that your team doesn’t have this kind of person. Even though skill is very important, you should make sure that the person is a team player. P.S before you judge the first person, he actually did a lot. It’s just his action that is regretable at that moment.
“Read my code so you know what to pitch about” — dev to hustler
As the developer or even worse, the lead developer, you should fill your team member who will pitch about what have you made, how it works, and what differs from the base idea. I said that pitching contains a pinch of bullshit. I must add that the bullshit must be a sensible one, so the hustler must know what he/she should boast and what to avoid.
“I’ll help you code” — hustler to dev at midnight
If you are the developer, politely refuse and tell the hustler to get some rest instead. Or if they don’t want to rest, tell them to practice their pitching. They won’t be able to pitch well if they don’t have enough sleep (and probably less confidence during pitching if they know how bad is the application). Plus, they won’t be able to help much with your code anyway.
“Just code as fast as possible, no need to worry about clean code.”
This is the right moment to say “Duck you, I won’t turn my code into a ducking mess”. After all, by keeping your code clean, it will help you to make a better application in a shorter amount of time. The problem with those folks who said those kinds of thing is: they don’t count their “debugging time” into total development time.
If you can’t make the app in 24 hours, then cut some not-too-important features, but keep the main flow as good as possible. (Your hustler friend won’t have time to promote your sophisticated authentication system anyway)
“You only have 3 hours left” — a ducking hustler to dev
I know, no need to remind me. It simply made me nervous. Thanks anyway, and please don’t remind me every 5 minutes.
“It’s hopeless” — a ducking dev to hustler, 5 minutes before pitching
Unless you are clearly incapable, there’s a good chance that other competitors are also cutting huge chunks of their application. Don’t make your hustler pessimistic.
That’s all misconceptions that I have met throughout my experience. Thank you for reading.
<shameless-plug>
Ps. I’m open to interesting opportunities, be it project/part-time/etc. Contact me via LinkedIn.
</shameless-plug>