Not all hackathons are made equal. In this chapter we'll learn what different kinds of hackathons are so that you can decide which ones to sign up for.
Travel, Healthcare, Publishing are a few industries among others who regularly organize hackathons. The organizers are mostly organisations who are already in the business. These could also be media houses wanting to throw a hackathon within their industry to get attention. These hackathons aim to disrupt the industry they relate to.
As these are industry specific hackathons, they sometimes do require some prior domain knowledge. Here are some kinds of industry hackathons and what may advantage you to know before attending the hackathon. Don't be intimidated by these topics. A true hacker is always looking to learn something new. If you are passionate about the industry, learning about these would initiate you and attending a hackathon will engage you with the industry. That is quicker than waiting to land a job in any of these industries to start learning.
- Travel Different kinds of booking engines. Flight reservation engines and APIs. price comparison engines. Iternerary builders. Mapping solutions and APIs. Path algorithms and services. Cloud Storage and Compute infrastructures. online travel regulatory information. Etihad, Booking, Emirates, Priceline, Expedia regularly hold hackathons.
The most improtant skill you need is the passion for this industry enough to know the problems or challenges that remain to be solved. Do you care about passenger boredom on long layovers or think there is a better way to track lost luggage? Know a way to increase hotel bookings or make the in-unit experience better for vacation rentals? This is the kind of hackathon you need to be joining. You don't even need to be a programmer for these hackathons.
- Healthcare and Medicine patient data formats scientific data formats disease or function specific algorithms and formulae. public data sets visualisation tools medical imagary tools
Hackathons are not always about launching the biggest most bad ass product within a weekend. Its about small changes that improve lives in substantial ways.
-
Publishing
-
Space
To understand different kinds of hackathons, one must understand the core nature of software development. Its about "information processing" and "problem solving". After the invention of writing we have exponentially grown our knowledge channels. Documenting personal exerpiences and taking empirical measurements to creating financial transaction processing systems and medical expert systems. There is software that helps you add data. Then there is software that helps you edit and clean it. There is software that 'generates' data, this kind helps you run experiments. there is software that processes this data. Processing has different natures. FOr instance, "transformation", reduction, deduction. the prcessing can be of higher degree as well. There are software that convert data to information and then from information to knowledge. Consider a police department in a developing country that is tracking its crime data in manual logs. This creates a slowdown in terms of adding and searching. its not extensible. its not secure. the data is not easily shareable either. hence it doesn't even live up to the first degree of information processing. During a hackathon you might start with a way to help police officers log this data more easily in a central place (an app perhaps?). Another hackathon might be to take the data and clean it. A data scientist can go thru several months of data, perhaps several years and "visualize" it and create algorithms to make predictions. This level of problem solving would never have been possible otherwise.
While there are specific data hackathons, data hacks show up more often than other categories. In one of the civic hackathons I attended in Islamabad Pakistan, people mapped out school data (which was gathered using a system made in an earlier hackathon). Having a geographic data is helpful but that is not the only kind of visualisation. The data was visualized on many important categories such as facilities available at the school, the teacher quality, the teacher to student ration and so on. At the NASA SpaceApps hackathon a team gathered the water flow data and created an interactive system to visualize it.
Things that hold you from joining a hakcathon
Things that people do wrong often
-
over-negative/cross-questioning In this case people try to outquestion each other while brainstorming and try too hard to break the idea in order to make something truely spectacular. The arguments usually take the form of "that's not possible because..." or "if we do this, then feature X will break...". An over generalized argument is "why care for someone's health. he is going to die anyway, eventually".
-
neat freaks You don't have to care about your design patterns.
-
initiation deficit If you have signed up for a hackahton and showed up for it, congratulations. You have already overcome a form of initiation deficit. Initiation deficit is the inability to get started on an endeavor no matter how simple it is. But its common to experience initiation deficit when a hackathon starts. You have an idea nand it sounds reasonable but now you don't know how to start.
-
general inexperience if you find yourself looking at "how to" tutorials and beginner level things for a technology you are going to write your hack project in, then you are in experienced in it. While it is fun to learn new things, its not so fun if that is not your intention. Creating a product and learning a new technology are both hard work. Doing that in a span of 24 hours is a lot of work. If you want to get things built, pick a technology you know really well and use it. It doesn't matter if your friend told you to make a website in django. If you know PHP, go for PHP. Learning Django means learning python and may even require learning a different kind of ORM.
-
not communicate there are joys in coding and the most joyful time of coding is when one in 'the zone'. this could mean cutting off from the team and the event for a considerable amout of time. This can prove to be fatal in different ways. First, keep integrating your hack with rest of the team members and make sure your work is compatible. You don't want to an incompatible software system. Secondly, seek and provide help. Its okay to ask. Its okay to not know a few things. Yes you can "google it yourself" but sometimes having a real conversation is more helpful than reading a blog. Finally, you can compound your hackathon fun by getting in on other projects. Take a break, walk around and socialize with other groups. See what they are making and learn what they are doing. at the end of the day, its the personal connections that will be more memorable than the thing you built.
-
posessive ideas An important principle for startups is to ship early, fail early. A typical trait of new hackers is that they get married to their idea in the inception stage and find it really hard to let go of it for something better. We are all buzzing with ideas all the time. Your brain is an idea generating organ. Like David Allen says, your brain is for "having" ideas not "storing them". Jhonny Ive says that one of the crucial components of his relationship with Steve Jobs was the mutual understanding of how "fragile" ideas were. One second they are there, the other they are gone. While I do highly recommend taking each idea seriously; at least enough seriously to put it down in writing. But once you have chosen an idea, keep the options open to pivot from the idea or dump it altogether. Here are a few ideas to ease the process of pivoting:
How to select an idea
- Develop a habit to capture your ideas. There is no science to when an idea will be concieved. It can be anytime and anywhere. Your mind is constantly taking input and processing those inputs. Two or more seemingly unrelated inputs can fire a certain permutation of neurons which give birth to a new "kind" of "thought". We call this thought an "idea". [Parallel neurons]. The most novel of these neuron combinations only fire for a nano second but our executive brain is able to detect it. The trick is to capture it because our brain is not very able to rememeber it for long. This is why you forget your dreams (and interestingly, the way to improve your dream rememeberance is to write them first thing in the morning).
You can keep a notebook or use an application or even email or SMS yourself the tagline for the idea to capture it. If you are the talker, record it. Quiet a few times you will realise that when you review your input a few days later, you have no idea what you were thinking about. This is a case of low-fidelity capture. Try to add as much context as possible to your ideas. leave the editing, categorization and triaging for sometime later. Limit yourself to "capturing" only and refrain from "evaluating". Stop the nay-sayer in your to speak up at any time during the capture phase.
The second most important habit you need is the review these ideas at a regular basis. The review process starts with going thru each idea and simply cleaning the text in the first pass. In the subsequent passes, you can 'tag' your ideas in different categories as you may seem fit. Remember, that even at this point you are not 'evaluating' anything. The idea could be as dopey as building a waterline from newyork to san leandro, CA to solve the drought crisis.
The third phase is a "brainstorm" phase for a particular idea. Most people who have a hard time delivering an idea to reality fail to segregate "brainstorm" from "planning". All these activities of a creative process, though iterative, are different activities and require different mindset. Timebox the brainstorming session to 5-50 minutes and generate more ideas (deliberately this time) around the topic. Its important not to simply come up with ideas, you have to comeup with principles and purpose, the vision, the outcome you are expecting. Don't be self-critical - but expansive.
The fourth phase is "planning and organization". At this point you take your brainstorming notes and organize them into "components", "priorities" and "sequences". You can use some arbitrary unit for estimation or even sort them by how clear you are about something.
Depending on how big a project you are undertaking, "planning and organiation" can again take from 5-50 minutes (or even days but it falls short of ship early, ship often philosophy).
The last phase is "scoping and doing". In a hackathon you are time constrained. You are also constrained by some other factors (for example, you might not have access to certain APIs or certain data sets - or even certain people you require on the project). Given these constraints, you will have to narrow the scope of your project. You can follow the "MVP" process here. You are also not sure about the "market validation" of your hack. Hopefully, if your brainstorm was thorough, you would have figured out who your target user is, what problem you are going to fix and how many people actually have that problem. If you haven't captured these metrics, you would have touched on them to do it once you start the project. At several points during the plan, keep an option to sack the project or pivot it. Hence you need to create a scope of your project. I prefer defining a few versions and checkpoints upon which I will review those versions. Once you have scoped a few things form your original plan to your first checkpoint (or first few checkpoints) you can start assigning things to your team.
It is important to engage your team from step 3 onwards. Step 1 and 2 is expected from all team members ideally. In that case, everyone can combine their captured ideas into one big list. For example, they can do some homework a couple of days in advance to pick 5 ideas from their ideas backlog to bring ot the table for hackathon. If you have 3 members, you now have 15 things you can potentially build during a hackathon. You can add a collective idea selection phase after phase 2 in which you put all your ideas on the table and spend an hour or so deciding which 2 or 3 ideas are worth doing or are doable. At this point you do not know much about the details so its good to have several options in case you decide to pivot down the line (when the devil in the detail shows up).
So the whole process is like this: Phase 1: Capture. Frequency: all the time. People: everyone. Where: private, individual lists.
Phase 2: review. Frequency: every 7-15 days. people: everyone. Where: private, individually.
Phase 2.5: Idea collection for an event. Phase 2.6: Idea selection for an event.
Phase 3: idea brainstorm. Frequency: infrequent.
Phase 4: idea planning and organisation
Phase 5: idea scoping and doing.
These are mostly guidelines and I do not advocate processifying the hackathons. Strict processes bring rigidity and people tend to lose the fun and sponteneity of hackathons while trying to follow a strict process.
=============================== Hackathons I have attended:
- space apps 2015
- civic hackathon 2015
- yelp hackathon 18 2015
- lahore startup weekend 2015
- HackerRank hackathons
- TopCoder SRMs
Major takeaways so far.
Learn about who the judges are, who the investors are, what were previous projects at similar hackathon, who are the mentors, which teams have participated, etc.
Capture everything all the time even if you are not participating actively in any hackathon. Ideas are really fragile so make sure to have an idea capture tool near you all the time. Simply capture and spend an hour a month going thru the ideas and triaging them. It will give a lot of confidence before entering or signing up a hackathon. Always explore ideas, tools, technologies and products. Be aware that an idea list is not a place to pass a judgement on how good or bad an idea is- just capture it.
A hack list is a set of technologies you would like to hack on. Keep this list as your stumble across things that excite you. Hackathon is all about getting excited, gaining momentum and leveraging that momentum to build something new. The opposite of happiness is not sadness, its boredom. So what makes your excited makes you happy. To maximize your happiness, hack on something that excites you. How awful would it be to draw a blank when you ask yourself, what will excite me in this hackathon?
Have a go-to language that you know really well. This is very true for competitive programming competitions but also in product building hackathons. Sticking to your favorite language such as python for web programming will greatly reduce the stress and you will be able to focus on more important things. Do not attempt an MVP hackathon if you don't know the technology very well. You will stumble across small issues that will destroy your hackathon if you don't know how to get around them.
Learn a stack. Any stack. Stay within your stack. Web is a great platform to tease out ideas. Learning a web stack will give you immense power to articular your idea into an MVP. Do not learn just PHP or Python, learn the whole stack including Apache, MySQL, AngularJS, CSS, etc. Trust me, you don't want to waste the whole hackathon simply solving JS dependency issues.
If you cannot draw what you are going to build, you may not be able to build it good enough - especially if you are in a team.
Really whet your team during socializing round for compatibility and technology. It will be a miserable hackathon if you have to ask for what you can work on or someone nagging you all the time about something or the other to teach them.
Build team with compatible skills (iOS+Android does not work. Node+iOS works. Drupal+Design works. App designer + game designer may not work if your aim is to build a product). A new learner can slow down the whole team. A thing to ask is, "Is my skill set compatible with my team?". Its better to say no early than feel sorry for rest of 24 or 48 hours of hackathon.
Have a designer on call even if your ideas are not design heavy. A designer can mean the difference between a mediocre and killer MVP. A designer can even make your business plan more beautiful and give valuable advice. Mostly you don't need to code all the edge cases. A simply mockup and click dummy would do just as fine.
Forget about "its been done". Life has been lived - but you don't stop living, right? Everyone's nature, nurture and experiences are different. Even Zuckerburg wouldn't invent Facebook if he had to today the same as he did so many years ago. Want to build a social network, go ahead! Make sure to elaborate on your value propositions though. Build that app you feel excited about even if everyone tells you it has already been done.
Its easy to lose data so make sure you know your tools properly and all team members are using it.
Use a PM tool early on. Simple as simple as Asana or Wunderlist is good. You simply need a way to capture ideas, triage them and categorize them. If you have access to a whiteboard, a Kanban board works too.
Separate brainstorm from planning and time box both. There is so much energy and everyone has advices. But the truth is that you have limited time and you want to get out with a solid something to show. So brainstorm 20-30 minutes for idea generation and welcome all ideas. Then spend an hour or so planning from the brainstormed ideas and cut down as much as possible to make it a doable scope. Identify risks and make them visible to everyone.
This is the holy grail of your hackathon. This will motivate to spent another hour, write 100 more lines of code. Be aggressive. Take risks. Pivot and restart if you have to.
Get plenty of sleep before the hackathon. If you plan it well, you can get sleep during the hackathon too!
Don't over caffeinate if you don't have to. Do what makes you most productive - but red bull will not give you wings or magically make your AngularJS learning ability double for the day.
Don't over feed yourself. It will make you sleepy. Try to eat a small meal every few hours. Know that it takes 20 minutes or your stomach to realize that it has had plenty. Some foods will make you sluggish. Sweets are good in small quantities.
Get all your other affairs in order - turn off the phone or put it on "Do not disturb" mode. Make sure to inform friends and family ahead of time to not disturb you during these hours. Don't come to a hackathon unless you are fully committed to it.
Rely heavily on 3rd party components. Hacking is not only about taking things apart for the sake of putting them together or building from scratch, its about make a sum greater than the parts. Find parts which work in a more novel way together.
Identify your goal for the hackathon from the following:
- Learn a new technology (hack list, pet ideas)
- Make an MVP.
- Tease a concept.
- Make a business plan.
For 1, you need a list of technologies you want to learn and define what 'learn' means. Focus on the end result. Do homework. Build something similar to what you have already built. In words of marie monterssori, when learning a new concept - make some things constant. For example, when kids are taught colors and shapes, don't give them a blue circle and red square and expect them to not mix up what red and square means. Give her a red square and red circle and they will be able to learn what shapes are - and if you want them to learn colors, give them a yellow circle and blue circle. Similarly, if you have built a calculator in .NET for desktop but want to learn angular JS.. make the same calculator. Ideas are very effective at hiding the complexity under the wraps of simplicity. You don't have time to unravel this.
For 2, you should really have a good command on the stack. You should know how each component in the stack works and what your limits are within it. If you are consuming APIs make sure you know, in your stack, how to efficiently parse and store JSON or XML. Learning it on the go is going to waste time. A hack around this is to use a third-party component.
For 3, know a very good prototyping tool and have a good designer. As it eventually is all about presentation make sure you know your tools very well. Clarify early on what your prototype will be (a slideshow, click dummy, working prototype?). Unless you have design skills (visual and functional), do not attempt to tease this. It is not easy. Like I said earlier, complexity can be hidden under the layers of simple ideas.
For 4, know your numbers. Know basic finances. Know your market and know your user base. have a designer and work on polishing the presentation. Poke holes in your business plan.
"Having fun" is not a goal. The fact that you showed up at the hackathon means that the fun has started. Now is the time to go through the pain.
You will need experience in any of these categories to gain reasonable results at the end of the hackathon. Experience hackers can aim for multiple or even all of the above goals but it is going to be incredible hard. I do not recommend for beginners as even I don't consider myself to be at that level yet. (does it even exist?)
Balance pain and pleasure.
Work backwards if there is a presentation involved. Think about how your demo would be like. Think of the mimic possible demo wit hate maximum possible effect.