I’m New, How Do I Start?

Many hackers attend their first hackathon and aren’t sure where to start. What’re we supposed to do at a hackathon? Heck, what even is a hackathon? Should we show up with a team or look for a team? What should we build? How should we build it?

Hackathons are a supportive space to create a cool product that solves a particular problem you care about, and it’s a chance to do some non-academic, real-life projects that almost always involve building an end-to-end app of some sort with other people that you may or may not know before the hackathon.

The most important aspect of a hackathon, I think, is to learn. It almost doesn’t even matter what to learn. Hackathons usually have workshops, and if one or a few of those strike your fancy, go for it. If learning a new framework, technology, or programming language sounds exciting, go for it. If honing your skills from the last hackathon or school/side project that you did is calling you, go for it. Learn something new, because that’s the whole point. And having fun, of course.

For workshops, there’s usually a schedule with when the workshops will be. Find the schedule by searching for it on the internet, and if you really can’t find it there or through all the communications done by the hackathon organizers, then ask the hackathon organizers. As a side note, there’s also the theme and list of categorical prizes usually on the hackathon’s devpost, a website used for hackers to upload their pitch and demo, as well as do a write-up on their hack.

If you have questions related to the logistics of the hackathon like schedule of workshops, themes and categories, which Slack/Discord channel to find a team, or anything else that’s not directly related to your project, find the channel with the hackathon organizers and ask them, not the mentors! Mentors are usually not involved with organizing the hackathon as they’re usually from companies or schools to help hackers with their project and not with logistics, so you’ll have more luck asking the hackathon organizers directly.

Who should you do this hackathon with? Well, if you already know people going to the hackathon, partner with them. Or not, if you want to meet people. If you have an idea, try to pitch that idea and get people to work on it with you. Most hackers go in the direction of listing the skills they have, but I’d put a lot more emphasis on the idea over the technical skills, assuming you already have an idea.

If nobody wants to work on your idea, you should definitely feel empowered to work on it yourself. However, if you don’t have an idea and want to work with others, then introduce yourself to everyone with the skills you have. During virtual hackathons these days, there’s always a thread to find team members. There is the standard way that everyone tries to find teams, in that they try to find others with similar skill sets. A lot of people generally think picking people who have the same skills is good. It’s not, to some extent.

Here’s why. If you’re building a web application, you’re going to need people who can do front-end, backend, and connect front-end to backend. If your entire team consists of people who only know Javascript, HTML, CSS, and perhaps one of the popular front-end frameworks like Angular, React, or Vue, who’s going to do the backend and deal with databases? Who’s going to connect the front-end to the backend?

I do believe though that those who are creating a mobile app, whether that’d be an Android, iOS, or Flutter, having a team who all knows how to do that would be helpful. (As a side note, if you don’t know what Flutter is, check it out if you’re interested in mobile! You write code once in a language called Dart and it generates a native Android, native iOS, and native web app!)

So, how to pick people? If you’re doing a web app, pick people with different skills than you, teams that are missing your skills. But, if you’re doing a native mobile app, pick people who know how to do that or want to and can pick it up quickly.

Now that you have a team, what should you build? Some hackathons have themes, others don’t. Some hackathons have prizes for particular areas, some don’t. Check out what the rules and prizes are, and pick one (or none, if there are no themes and you don’t care for the prizes).

Then, sit down with all your team members and if there’s no idea yet, do a round of rapid unconscious fire. Have every member open an individual doc (can be Google doc, Microsoft Word doc, a draft email even) where s/he can type, set a timer for three minutes, and just brain dump anything. Good or bad, everything. Nobody else will see what you’ve written down aside from you.

When the timer is up, pick your top two ideas and share with the team. From there, discuss and narrow down to three total as a team, and really try to flush those out a bit. What would be the bare minimum the team has to do in order to make a complete app? What’s the problem the app is trying to solve, and is it interesting to everyone? Is it technologically possible to make?

Keep in mind that since you only have somewhere between 24 to 48 hours depending on the hackathon, you won’t have time to make the fastest, shiniest, best app in the world. Plan for the bare minimum, then add to it after you already have that finished.

With the top three ideas, pick the one that everyone likes the most. Discuss what technology to use: should it be a web app or a mobile app? What technology does everyone know already? Python is a common language, what about Flask? Or if Javascript is everyone’s common ground, what about an Angular, React, or Vue app with a Node.js backend? For mobile, if everyone knows Java and/or an object-oriented programming language, then Android sounds good. Or try out Flutter!

From there, quickly do some rough designs on how the app will look, and split up the work. I know how easy it is to get carried away and want to build everything you can ever think of for your app, but realistically, that will not happen. We don’t work that way in industry at a job, and it won’t happen that way in a hackathon. Remember again, there’s only a short amount of time, so it’s incredibly important to set realistic expectations and keep to the bare minimum. Decide on a MVP, a minimal viable product, the bare bones of your app, to ensure you have a working product to turn in at the end of the hackathon. If your team has extra time, then build additional features, but keeping the app to the bare minimum will more likely ensure that you have a finished app rather than trying to do too much and have nothing working.

After the MVP is determined, set up a Github repository so everyone can share code, and get the basic template and groundwork up and running together, mostly meaning make a Helloworld app so everyone has a code base to work off of.

So there you go. Form a team, brainstorm ideas, determine a MVP, pick the tech stack, do some basic design, split up the work, and off you go! Oh, and don’t forget to ask team members or mentors for help while you’re at it, and most importantly, have fun!