Monthly Archives: June 2014

How to “kill it” at a hackathon

I’ve participated in a lot of hackathons over the last few years and luckily even won a few. (TechCrunch twice, Facebook, Angelhack) Hackathons are a great way to try out a new idea and get immediate feedback from the community.  They’re social, challenging and always a blast.

But sometimes they can be extremely frustrating due to poor planning, crunched time and various other factors. Here are few lesson’s I’ve learned the hard way, but I write this in hopes of saving you some pain.  Here’s what TO DO, if you really want to “kill it” at your next hackathon.

Show Up With An Idea

I can’t even begin to tell you what a bad choice it is to show up with no idea of what you’ll be working on.  I’m going to be stressing this fact, on every bullet point, so here the first time.  Your time is extremely limited. You don’t have time to wander around trying to come up with an idea of what to build.  You should come prepared with at least a vague idea or two, of what you’ll be working on.  Now, I’m not saying you have to have it completely planned and mocked out, but come with a plan.

Also make sure that the problem you are trying to solve is actually a problem.  Ask a few friends if they would use it.  If you can’t find any takers, chances are the judges won’t either.

Sell The Idea, Not The Code

At the end of the day, you’re presenting an idea to the audience and your job is to sell it.  The code doesn’t have to be pretty or work flawlessly.  In fact, no one will most likely ever look at it again.  Focus on what problem your trying to solve and gear all of your effort towards demoing that. Visually.  Sell the crowd and judges on what makes your concept, not your code, amazing and disruptive.

The truest code ever written at a hackathon. Not pretty, but it will work.

Stick To What You Know

A lot of people use a hackathon as a time to try out a new frameworks and even programming languages.  If you goal is to learn, have at it. If you want any possibility of winning, stick to what you know.  Your time is limited and you can’t afford to spend 5 hours learning how to use a new 3rd party API, a new language, or anything else new.

Prepare For Bad WiFi

The wifi will be slow so prepare to work and demo locally.  This gives you the huge advantage of faster iteration cycles during development and a demo which is fast and smooth.  Why hinge your entire project on an uncontrollable external factor?

Deliver A Great Demo

Remember the demo is the ONLY thing any one sees at the end of the day.  Make sure the demo is clear and gets your idea across.  In addition, practice your presentation over and over, making sure you articulate the problem and how your project solves that problem.

With these time saving tips in mind, I wish you all the best in your hackathon endeavors and hope you have a blast at your next hackathon.

ReactJS – Componentize all the things

Been taking a look at ReactJS over the last few days, which is an interesting view library from the folks over at Facebook.  What I really like about it so far is the “componentization” of  objects on a page.  The general idea being,  any part of the page should be able to stand on its own.  Think widgets.  In theory this is a nice idea until components need to interact.  For example, a list of items with a search box that filters the results.  Component 1 is the search box, Component 2 is the list of items.  In the traditional MVC pattern, the controller would be responsible for handling this interaction.  In react, you would create a parent component which would handle the passing of state change to the list component.  It doesn’t really matter what the parent component is, just that its children are the list and the search box.

Considering the issues I have with the traditional MVC pattern for front end web apps, I’m interested in how this approach by ReactJS performs in the real world at scale.  Especially on very interactive web apps.  In past large web apps, I’ve used an event bus to facilitate the communication between components and thereby reduce tight coupling.  My initial concern is that there will be hooks and callbacks being passed through each component in ReactJS, making the code a challenge.

Time to dig in and see the real world results.