This is a continuation of my previous post on how to win a hackathon - 1. There, I have discussed some important things to do if you want to win a hackathon. If you didn't read it, please go ahead and have a look ^^.
However, it would be great if you know the panel of judges who are going to review your app submissions. This is a very important perspective of the project that you are going to work on during the hackathon. If you know who the judges are before you start building your app. Then you have to think of the psychological perspective of the judging panel.
Judges from non-technical fields
Let's say the judging panel includes some people from the top management from a company, investors, venture capitalists, entrepreneurs, or CEOs. Then, your impression of the project should be mostly the business perspective instead of the technical perspective. It doesn't mean it should be not technical at all, it really should be technical enough to qualify to the hackathon. However, while you pitch your project idea, it should be heavy from a business perspective.
You will have to provide an idea of use cases, target market, ROI (return on investment), so and so. You may be not so good with the business side since of course, you are a techie, but you have to simplify your brilliant idea as it can be understandable from the business person.
Sometimes, even if they are someone from management or an entrepreneur, still they may have some basis of designing, customer relationship, or user experience side. Then you will have to more focus on the look and feel and the user experience of your application. Still, you will have to simplify the hardcore technical side of it as it can be easily understood by the judging panel.
Judges from the hosting company
Another scenario could be, a judging panel from the hosting company itself. In that case, the best thing to emphasize with your project idea would be to the impact that it can make on their products. Or how they can improve their existing product with your solution. Or how much revenue it would generate because of your new solution. And how much of your application could seamlessly integrate their APIs or the platform. If your project uses their APIs and it has a huge impact on how people would be interested in using your solution, then there is a higher chance of winning.
If the judges are from the same hosting or sponsor company itself, you have to understand why would they be so generous and host this event in the first place.
In most cases, this is because of 3 things.
1. As an advertising campaign
2. Do some beta testing on their APIs or platforms
3. They need more ideas and more products to build upon their APIs or platforms.
Either case, if you have used more APIs and platforms from their products, they will be really happy about it. Also, they would love to brag about it and advertise it in some magazine and in their blogs. If that is the case, the chances are higher if you have used more products from the hosting company in your solution 😉.
Judges from technical areas
This could be really fun and simple for a techie developer. Because the judges practically speak your language, so you don't have to simplify any technical stuff or sugarcoat anything. You wouldn't get that feeling like you are speaking to a muggle.
It will be easier to talk to them but you can't really cheat at all (which you shouldn't in the first place). You should Never cheat at a hackathon!
However, with these types of judges, your solution should be technical enough. Still, even you don't specify the business aspects of it, they would still be interested in your solution if it is a cool technical solution.
If you don't have a team, and at the hosting premises (or online) you have to pick some random guys then you don't have that freedom.
However, what you can do is, to work with what you have. You have to identify the capabilities and weaknesses of your team. You have to figure out who is good at what. Also, you have to carefully decide the tech stack based on the skills of your team. It wouldn't make sense if only one person is good at Java and others are PHP devs and you agree to code in Java. You will have to work with what you got without leaving anyone behind.
The best way to do it would be to divide and conquer. So it would cover a lot of ground at the same time. However, it is important to communicate with each other frequently so anybody doesn't go derailed and implement something not compatible with the rest of the components you develop.
At some point when you guys are tired and sleepy, the progress and the productivity might go down. Also, you might run into some issues and stuck with it. One of the options you could do at that point would be to do pair programming. Even if you both are sleepy and tired when you both work in the same screen side by side. It could be much faster and productive. Besides, you won't feel sleepy because the other guy is looking over. If you are stuck with an issue, borrowing some fresh pair of eyes would help you out in most cases.
As we discussed above, the tech stack also has to be discussed and decided based on your teammates' capabilities. Yet, most of the hackathons would specify a tech stack or some platforms you must use in your solution. In that case, you will have to stick with it anyway.
Hacking
As the Hackathon the name itself implies, hacking would be a really fun part of it. It doesn't mean an illegal type of hacking as a cybercrime.
Hacking is some clever shortcut a developer would use rather than doing something conventional and time-consuming.
It could be sometimes like using an existing system for a different purpose. For example, once we have used a public RSS feed as an API to extract some information instead of building a new API from scratch.
Also, it could be something like using an existing open-source library but changing it slightly to serve a specific purpose in your project.
Boilerplate code
Boilerplate code would be something already developed halfway with the most initial pieces of code. For example, it can be a code with a basic login page and the DB connectivity. Or a basic messaging code with only a hello world message implemented.
Also, you can consider starting from a hackathon starter pack code to save the time that you would have to spend on basic housekeeping coding rather than the important features of your application.
If you don't spend your time on the important features of your app, you might end up half a day or more only completing the login to your app.
I've listed some of the boilerplate repositories and starter kits below.
A boilerplate for Node.js web applications.
https://github.com/sahat/hackathon-starter
React Slingshot: React + Redux starter kit / boilerplate
https://github.com/coryhouse/react-slingshot
Yii2 Starter Kit
https://github.com/yii2-starter-kit/yii2-starter-kit
Express Typescript Boilerplate
https://github.com/w3tecch/express-typescript-boilerplate
Angular Full Stack project built using Angular, Express, Mongoose and Node
https://github.com/DavideViolante/Angular-Full-Stack
Go Restful API
https://github.com/qiangxue/go-restful-api
Laravel Boilerplate
Hardcoding
One of the tricks you can do for the implementation is to hardcode some stuff in your codebase. By hardcoding, it means you can write a code to provide some dummy output just for the demonstration purposes just to show how your app should work like.
By a hackathon of a short time, it is never expected from you to implement a 100% completed product without any bugs. If you can do, that's great but it won't be possible in most cases. Therefore it is ok to hardcode some of the not important functionalities unless the hackathon rules say otherwise.
What you can do is, design your app. Then hardcode the functions that you wish to implement first. Then according to the priorities, start working on the real implementation.
Use a version control service
Most of the hackathons mandate you to use a public version control service like Github or Gitlab because they can monitor and check if you are cheating. It has to be a real project built from scratch with progressing code commits. Even if they don't, using a version control system would be a great idea because you are working with a team and to make sure you don't delete the project accidentally. Also, it will be really easy to integrate your pieces of code into a single project with branching and merging.
When starting the project, you should have a plan to when to do what. For example, you have to divide this many hours to design, this many hours to implement, by this time we are going to integrate, etc.
Most important part is having some allocation to finish up all your work. Allocate some time to integrate and handle issues when you do the integration of each piece of work done by the team members.
Lastly, keep some buffer for the testing and bug fixes as well.
To make it ready for the submission, this is the time you can do the final touchups. Like formatting, color changes, slight CSS adjustments, writing missing UI text, etc.
If there is anything you couldn't complete, you can either remove them from the project if it causes to crash your system. If it is not, you can maybe hardcode that piece and do the demo.
Pick somebody from your team who is really good at presentations. It even can be two people, it doesn't matter. Communicate your problem statement and the solution clearly with facts. Adjust your presentation depending on the audience and the judges. Prepare a couple of slides if it helps, but don't make more than 5,6 slides. Don't add lots of texts into your slides, add more images, and explain what you mean from them.
For the demo, use a perfect happy path of your solution. Input some dummy data but it has to look realistic. For example, if you built an app with a food menu, don't fill it with dummy data like "Test food1, Test food 2". Insert some meaningful data like in an actual scenario. So my food menu items would be like "Veggie burger meal, Cheese Kottu" (If you don't know hat cheese kottu, look it up! It's an awesome Sri Lankan dish)
Presentation makes a big impact to your winning. Even if you don't code a single line, still if you manage to impress the judges with your presentation, still you may win it (unfortunately I've witnessed these kinds of winnings in real hackathons 😲). It doesn't mean you shouldn't do any work at all but only prepare for the presentation. You must work for the implementation as much as you can, also spend enough time and give priority for the presentation as well. For a good presentation, final 30 mins will be enough to make 5-6 slides and plan some context.
Yes, a good presentation can make you super!
4. Know your judges 👨⚖️
Most of the hackathons, they will publish what are the judging criteria and what the expectation of the app you are building. One of the most common criteria would be the relevance to the theme. It would be of course has to be considered during finalizing the idea. We have discussed this part in our previous post.However, it would be great if you know the panel of judges who are going to review your app submissions. This is a very important perspective of the project that you are going to work on during the hackathon. If you know who the judges are before you start building your app. Then you have to think of the psychological perspective of the judging panel.
Judges from non-technical fields
Let's say the judging panel includes some people from the top management from a company, investors, venture capitalists, entrepreneurs, or CEOs. Then, your impression of the project should be mostly the business perspective instead of the technical perspective. It doesn't mean it should be not technical at all, it really should be technical enough to qualify to the hackathon. However, while you pitch your project idea, it should be heavy from a business perspective.
You will have to provide an idea of use cases, target market, ROI (return on investment), so and so. You may be not so good with the business side since of course, you are a techie, but you have to simplify your brilliant idea as it can be understandable from the business person.
Sometimes, even if they are someone from management or an entrepreneur, still they may have some basis of designing, customer relationship, or user experience side. Then you will have to more focus on the look and feel and the user experience of your application. Still, you will have to simplify the hardcore technical side of it as it can be easily understood by the judging panel.
Judges from the hosting company
Another scenario could be, a judging panel from the hosting company itself. In that case, the best thing to emphasize with your project idea would be to the impact that it can make on their products. Or how they can improve their existing product with your solution. Or how much revenue it would generate because of your new solution. And how much of your application could seamlessly integrate their APIs or the platform. If your project uses their APIs and it has a huge impact on how people would be interested in using your solution, then there is a higher chance of winning.
If the judges are from the same hosting or sponsor company itself, you have to understand why would they be so generous and host this event in the first place.
In most cases, this is because of 3 things.
1. As an advertising campaign
2. Do some beta testing on their APIs or platforms
3. They need more ideas and more products to build upon their APIs or platforms.
Either case, if you have used more APIs and platforms from their products, they will be really happy about it. Also, they would love to brag about it and advertise it in some magazine and in their blogs. If that is the case, the chances are higher if you have used more products from the hosting company in your solution 😉.
Judges from technical areas
This could be really fun and simple for a techie developer. Because the judges practically speak your language, so you don't have to simplify any technical stuff or sugarcoat anything. You wouldn't get that feeling like you are speaking to a muggle.
It will be easier to talk to them but you can't really cheat at all (which you shouldn't in the first place). You should Never cheat at a hackathon!
However, with these types of judges, your solution should be technical enough. Still, even you don't specify the business aspects of it, they would still be interested in your solution if it is a cool technical solution.
5. Team up 👪
The team members can make a big impact to win a hackathon. If you already have a team before you go to a hackathon, then that is great and you have the freedom of choosing your members and discussing with them.If you don't have a team, and at the hosting premises (or online) you have to pick some random guys then you don't have that freedom.
However, what you can do is, to work with what you have. You have to identify the capabilities and weaknesses of your team. You have to figure out who is good at what. Also, you have to carefully decide the tech stack based on the skills of your team. It wouldn't make sense if only one person is good at Java and others are PHP devs and you agree to code in Java. You will have to work with what you got without leaving anyone behind.
The best way to do it would be to divide and conquer. So it would cover a lot of ground at the same time. However, it is important to communicate with each other frequently so anybody doesn't go derailed and implement something not compatible with the rest of the components you develop.
At some point when you guys are tired and sleepy, the progress and the productivity might go down. Also, you might run into some issues and stuck with it. One of the options you could do at that point would be to do pair programming. Even if you both are sleepy and tired when you both work in the same screen side by side. It could be much faster and productive. Besides, you won't feel sleepy because the other guy is looking over. If you are stuck with an issue, borrowing some fresh pair of eyes would help you out in most cases.
6. Develop smart 💻
Tech stackAs we discussed above, the tech stack also has to be discussed and decided based on your teammates' capabilities. Yet, most of the hackathons would specify a tech stack or some platforms you must use in your solution. In that case, you will have to stick with it anyway.
Hacking
As the Hackathon the name itself implies, hacking would be a really fun part of it. It doesn't mean an illegal type of hacking as a cybercrime.
Hacking is some clever shortcut a developer would use rather than doing something conventional and time-consuming.
It could be sometimes like using an existing system for a different purpose. For example, once we have used a public RSS feed as an API to extract some information instead of building a new API from scratch.
Also, it could be something like using an existing open-source library but changing it slightly to serve a specific purpose in your project.
Boilerplate code
Boilerplate code would be something already developed halfway with the most initial pieces of code. For example, it can be a code with a basic login page and the DB connectivity. Or a basic messaging code with only a hello world message implemented.
Also, you can consider starting from a hackathon starter pack code to save the time that you would have to spend on basic housekeeping coding rather than the important features of your application.
If you don't spend your time on the important features of your app, you might end up half a day or more only completing the login to your app.
I've listed some of the boilerplate repositories and starter kits below.
Angular Spring Starter
https://github.com/sahat/hackathon-starter
React Slingshot: React + Redux starter kit / boilerplate
https://github.com/coryhouse/react-slingshot
Yii2 Starter Kit
https://github.com/yii2-starter-kit/yii2-starter-kit
Express Typescript Boilerplate
https://github.com/w3tecch/express-typescript-boilerplate
Angular Full Stack project built using Angular, Express, Mongoose and Node
https://github.com/DavideViolante/Angular-Full-Stack
Go Restful API
https://github.com/qiangxue/go-restful-api
Laravel Boilerplate
Node-Typescript/Express Boilerplate with Authentication
These are some of them, but you can simply find an existing boilerplate or a starter kit just by googling with the technology that you use.
Hardcoding
One of the tricks you can do for the implementation is to hardcode some stuff in your codebase. By hardcoding, it means you can write a code to provide some dummy output just for the demonstration purposes just to show how your app should work like.
By a hackathon of a short time, it is never expected from you to implement a 100% completed product without any bugs. If you can do, that's great but it won't be possible in most cases. Therefore it is ok to hardcode some of the not important functionalities unless the hackathon rules say otherwise.
What you can do is, design your app. Then hardcode the functions that you wish to implement first. Then according to the priorities, start working on the real implementation.
Use a version control service
Most of the hackathons mandate you to use a public version control service like Github or Gitlab because they can monitor and check if you are cheating. It has to be a real project built from scratch with progressing code commits. Even if they don't, using a version control system would be a great idea because you are working with a team and to make sure you don't delete the project accidentally. Also, it will be really easy to integrate your pieces of code into a single project with branching and merging.
7. Keep Timing 🕒
Time management is important not only to win but even to complete your project successfully.When starting the project, you should have a plan to when to do what. For example, you have to divide this many hours to design, this many hours to implement, by this time we are going to integrate, etc.
Most important part is having some allocation to finish up all your work. Allocate some time to integrate and handle issues when you do the integration of each piece of work done by the team members.
Lastly, keep some buffer for the testing and bug fixes as well.
8. Finish it up 🎁
This is basically wrapping up the project to submit. As mentioned in the previous post, by the time you should have a better understanding of how the submission is expected to be.To make it ready for the submission, this is the time you can do the final touchups. Like formatting, color changes, slight CSS adjustments, writing missing UI text, etc.
If there is anything you couldn't complete, you can either remove them from the project if it causes to crash your system. If it is not, you can maybe hardcode that piece and do the demo.
10. Presentation 📣
No matter how great your project idea and how cool your coding is if you couldn't pitch it to the judges or the audience. The presentation could include a demonstration of your project and also some media to convey your project idea or the problem statement and how you have solved it.Pick somebody from your team who is really good at presentations. It even can be two people, it doesn't matter. Communicate your problem statement and the solution clearly with facts. Adjust your presentation depending on the audience and the judges. Prepare a couple of slides if it helps, but don't make more than 5,6 slides. Don't add lots of texts into your slides, add more images, and explain what you mean from them.
For the demo, use a perfect happy path of your solution. Input some dummy data but it has to look realistic. For example, if you built an app with a food menu, don't fill it with dummy data like "Test food1, Test food 2". Insert some meaningful data like in an actual scenario. So my food menu items would be like "Veggie burger meal, Cheese Kottu" (If you don't know hat cheese kottu, look it up! It's an awesome Sri Lankan dish)
Presentation makes a big impact to your winning. Even if you don't code a single line, still if you manage to impress the judges with your presentation, still you may win it (unfortunately I've witnessed these kinds of winnings in real hackathons 😲). It doesn't mean you shouldn't do any work at all but only prepare for the presentation. You must work for the implementation as much as you can, also spend enough time and give priority for the presentation as well. For a good presentation, final 30 mins will be enough to make 5-6 slides and plan some context.
Yes, a good presentation can make you super!
Cheers and all the best for your next hackathon!
Comments
Post a Comment