Guess who’s back… Yes, you are right. I'm back to share with you some tips to take the most of every hackathon. Now that we convinced you to join us in the force, now let me share you how to build your dream team and create a winning (or close to it) project.
Dream Team
The team is the crucial point of a hackathon. It is normal to have the group formed, or partially formed before the challenge, but there may be cases where one or more elements are missing. Or even you have the idea for the project, but you don’t have the team to develop it. The important thing is to form an excellent team. When I say excellent, it is not having the best data scientist in the world, or the best frontend developer. To have an excellent team, you just need to find different people and profiles that covers all the areas you need to create the best project possible in the time you have. Do you need a backend developer to develop an API? Do you need a UI Designer to have a presentable project and still give you an excellent logo as a bonus? Do you need a data scientist to analyze a series of data you found online? Do you need someone from the health field because the project requires you to understand specific needs with specific terms? Gotta Catch 'em All!
It is essential to have a team that can respond to the needs of the initial idea. Even if you are alone, you should not be afraid to look for the elements that you think can help you realize a particular idea.
At TAIKAI, we developed a feature that we called "Matchmaking", where both participants and teams can find what they are looking for. On the one hand, we have participants who can be made "available" to join a project. On the other hand, we have teams that can see the available participants but can also create positions that can be filled with particular skills. You can read more about "Tinder for Hackathons" in this article that Mário, CEO of TAIKAI, wrote.
The team will always be the key to success in the challenge. And that success will only be achieved if the team is aligned on the same page. Whether or not you know the team members, communication must always be present. What project to do, how to do it, where and how each one will contribute are examples of how conversation can dictate the success of a project.
Get to work
Most of the time, we have already know the themes of a challenge before the event, and this can be crucial, it is essential to take some ideas of what can be developed.
This brainstorming is essential because you need to understand what you are going to do and how you are going to do it. But more important is to know if it is possible to do it in the time that you are given.
It is quite common for a team to dive into a fantastic idea and start its development without even thinking about what they might encounter along the way. Later, they realize that after all, they will not be able to create what was planned, and that is not because the team is not capable, it is because they do not have time. Time is the biggest enemy in a hackathon. Time does not stop, and when the project comes to an end, it must be presented.
It is essential not to waste time on trivial things - we all know that even the most experience team can do it. How good can it be having the most beautiful logo in the history of logos? There is nothing more beautiful than a project developed in a few hours, and that manages to have an appealing look and feel. Still, there is no need to waste hours on end creating a logo. What is the point of having a project with a login system? Any developer with more or less experience ends up developing a login system, it's something that exists in all online services. What is it worth to waste hours collecting data to training an algorithm when we can probably find a dataset on the internet?
The important thing is to understand what the project needs, what are the really essential things and what can be discarded. Sometimes we are so closed in solving the problem that a right solution is to share the project with people outside the team. It is here that mentors can play a crucial role in giving their view of the problem and whether or not the project is on the right track.
All of this can even seem complicated and a little scary because time doesn't stop. But the truth is that it is the right time to develop something new in an area that is unknown to us, in which we have never worked, using a programming language that we have never used. The short time forced us to have a much higher learning pace, and this in itself already becomes a challenge that we certainly can take advantage of in the future.
But in fact, it is not easy to find the winning idea. There is no magic recipe that tells us which winning project to develop. The important thing is to understand the purpose of the challenge, what it intends to achieve, understand the problem you want to solve and what deliverables are expected.
The truth is that it is ok to develop an idea of an existing product. If it is better, go for it! The world is full of problems, but it is also full of solutions, right?
There's an app for that!
So, it is best not to reinvent the wheel. If we need to use an existing framework, no problem. If we need to develop (but better) something that already exists but in fact does not solve a problem entirely, no problem at all.
And about the code, there's no need to write the perfect code or the most beautiful code you've ever written. Let's be honest, when we are in hackathon mode, we do not accept pull requests, and there is no code review. We just believe that everything will go well and hope that all the things work... sometimes even without knowing how! Unless the hackathon has a "JavaScript Coding Competition", as is the case of Shift APPens, where in addition to the main challenges, projects developed with JavaScript are analyzed regarding its approach and structure.
But things don't always go well. There are many situations where "team" and "teamwork" can be critical. For example, when one of the elements no longer believes in the project, the rest of the team must understand why, what demotivated that person, what they can do to make him overcome it and get back on track. Or when the team realizes that the result that was initially expected is not the one being achieved. It is necessary to anticipate problems or at least perceive them on time so that if it is necessary to stop everything and start over again with a completely different idea. It was one of those situations that happened in the Salazar project and that I cover a little bit of the story in the article "First hackathon, first winner project".
Next week, we’ll talk about project evaluation and how hackathons can be a win-win situation.
Top comments (0)