Friday, December 20, 2013

How To Prepare for a Hackathon?

In a previous post I wrote of why I like to participate in hackathons. This time I'd like to talk about how to participate. What sort of prep work you will need to to get ready.

Understand the Theme and the Sponsors
You may have the most awesome idea for an app, but if it doesn't fit the theme of the hackathon you will lose. If the theme is "Teaching Kids", in some way your app must help teach kids. If it doesn't, you lose. 

So take the time to fully understand the theme of the hackathon. I recently participated in the Tizen Devlab and Hackathon in Los Angeles. The theme was to increase the apps in their store and to raise awareness of their mobile platform. The apps which won, including my own, were something the judges felt were both store worthy and could be finished in a reasonable amount of time. "Pie in the sky" apps didn't win.

Also take the time to know who are the sponsors and judges. If the some of the judges work for Yahoo for example, your app will probably be rated higher if it uses Yahoo's APIs. In many hackathons, use of the APIs is the theme. I have see developers make many mind blowing fails, like not using the API of the company sponsoring the event and instead using one of their competitors. I haven't seen any of those devs win yet.

Take a look at when the event start and ends. Make sure it is something that you can fit into your schedule. Not just the time at the event but the time you will have to spend preparing for it. You don't want to have to tell the judges that your app is crap because you didn't have enough time to prepare. Everyone gets the same amount of time. You should only participate if you are prepared to bring it.

The very first thing you should do in order to prepare for a hackathon is to read all of the instruction. This is more than just the web page announcing the hackathon, you will want to read everything. All of the rules, regulations, and the fine print stuff. The bigger the prize, the more thoroughly you should read everything. If you are part of team, every member should read the instructions. It would absolutely suck to have coded your heart out only to be disqualified in the end for a minor rule violation.

Keep a special eye out for things which would disqualify you like being an employee of one of the sponsors. Many companies have very complicated structures and you may not even be aware that your company and the corporate sponsor are both owned by the same parent company, which may make you disqualified. If you have questions, be sure write the sponsors ahead of time.

Create a To Do List
For nearly every hackathon there are things you must do. Some are explicit and others implicit, but all should be on a to do list. For example if you need to use a sponsor's API, it will help to know the API before the day of the event. If the hackathon is in another city, you may need to buy travel tickets or make hotel reservations, both things you wouldn't want to forget, plus you usually save money by doing them early. My favorite tool for this kind of thing is It is free and it is easy to use. But a pen and paper also works.

Scout the Venue
Google Maps is an essential tool for scouting the venue. If you are driving, it is critical to know where you are going to park. Some venues provide parking but many don't. Even when provided, the lot may be small and parking scarce. So I like to scout out the location. Find a free or cheap parking lot and map how to get from the lot to the venue. Be sure to be aware of city parking regulations. Few things suck more than getting a parking ticket or worse getting towed.

You need to make sure to pack everything you may need. I have seen devs scrambling around for items which they forgot at home at every hackathon I've attended. Things as crucial as power supplies or as easy to forget as a video connector. I travel with my machine so much that I have two power supplies and to video connectors, one travels, one stays home. I check my travel box before I leave home and the venue to make sure I don't forget anything. Most venues will have video connectors for PCs, if you are on a Mac like me, remember to bring your own. In order for judges to fairly rate your app, they need to be able to see it.

Think about the noise level of the event. You may want to bring headphones or ear plugs so that you can concentrate. I bring my headphones, their charger, and my USB cable to charge my phone. 

I also recommend bringing your own snacks. Most venues will supply snacks and water, but you are at their mercy as to what constitutes a snack. I prefer to bring my own snacks. Along this line, be careful of too much caffeine. I see people drinking energy drinks like water and you can see it "weirding" them out. I usually drink just one energy drink per event and I save it for that long period of time from midnight until dawn. To keep from falling to sleep, I usually focus on my to do list, listen to fast music, and go for walks when thinking. 

Get Plenty of Sleep 
The night before the hackathon be sure to get plenty of sleep. Many times developers try to get too much done that last night and wind up hitting the sleep wall and fading early. Instead, be sure to get at least eight hours of sleep. And avoid doing anything too strenuous, save all of your energy for coding. 

Arrive Early
There are many benefits to arriving a bit early: parking is easier to find, you can scout out a good location to set up (some place away from the restroom and kitchen), and you can unwind and get yourself into a good coding frame of mind. 

Know When to Say When
I have been guilty of coding until the last minute and it is a bad thing to do. The judges aren't expecting a finished app, but they would like to see a demonstrable one. Stand before them and trying to talk your way through a crashed app won't impress them. Instead stop coding before the deadline and make sure your app works. 

Use a version control systems like Git, can save the day. It will allow you to roll back to the last working version instead of wasting time trying to figure out what you broke. While Git is helpful to an individual, it is critical for teams. Nothing sucks more than when someone breaks the build and time is pressing. Version control helps prevent this immensely.

It also helps to spend a bit of time planning out your app. This is even more important if you are partnering up with others. The app needs to broken down into bite sized nuggets and everyone needs to know what they are doing. Once again Trello helps here.

Newbies continue to be surprise by the fact that they will have to present their app. Don't be. Depending on the hackathon, your presentation may be as much as 33% of your weighted score. Now, judges aren't expecting some salesman-slick PowerPoint presentation. What they want is for you to be able to explain usually in less than five minutes, why you think you app has won. This is time to state all of the things from the theme that you used. I recommend writing what you are going to say and present down. I keep 3x5 cards in my go bag. 

Be careful of is bluffing. The judges are usually tech professional and they can smell a lie a mile away. I was at one hackathon where a guy present this great parking, but when ask what was the data source, he crumbled. There is no central repository of parking data and building that up would be a endeavor which would probably require VC money. It was a lot more effort than could be expected of a small mobile app hackathon. The guy didn't win.

Please don't let this list scare you off. It does take work to win a hackathon, but not too much. Plus, there are hackathons for all skill levels appearing around the world. Some only last a few hours and are geared towards beginners and students. So if you are interested in improving your skills, having fun, and winning prizes, please participate in a hackathon near you. And if you see me, say "hi".

Monday, December 16, 2013

Tizen Devlab & Hackathon

On December 13th and 14th, I participated in the Tizen Devlab & Hackathon. The event, hosted by BeMyApp, was roughly 24 hours long with about 21 hours of actual coding. It was a blast. I ran into quite a few friends from the SoCal development scene. Everyone one was friendly and there was plenty of food and drink. I spent a good chunk of time helping less experience teams while working on my own app.

In the end my app, Lunch-o-rama, took the $500 runner-up prize. The first place prize went to a couple of students from UCLA with their 3D break-out style game. Besides the $500 dollars, I took home:

  • Tizen t-shirt
  • Mashery t-shirt
  • Tizen developer's device
  • PowerTrip - a rechargeable external battery for USB devices
  • Tizen for Dummies book
  • Leap Motion device (being shipped)

I am now working on finishing my app to get it into the store. I plan to have it finished by the end of the month. If I can get done by the 26th, I will also enter it into the appbackr Tizen Challenge and win another $200. 

My next hackathon will be at the AT&T Developer Summit at the Palms Casino Las Vegas, January 4th and 5th. This is a weekend event, so those of us with jobs, don't have to take time off from work. This one is a monster with two separate categories each with $25,000 top prizes. Second and third place will be worth $10,000 and $5,000 respectively. It still isn't too late if you haven't sign up yet, here is the link:

Monday, December 9, 2013

Why Hackathons?

I like to do hackathons. That fact, strangely surprises some who know me. They think after coding more than 40 hours a week, the last thing I would want to do is more code outside of work. And they're wrong. No only do I like it, I like it more.

When I first began programming it was about having fun hacking code. I would simply think something up and start to build it. Now, I rarely finished anything, instead, I would finish enough of the idea to see if it was viable. In many ways, I was doing private hackathons long before I had actually heard the term.

As a corporate developer I rarely get time to have fun. My time is a precious commodity and must be allocated against projects. Projects need to be planned, allocated, and budgeted. Even the most trivial idea can take weeks to work their way through the system. More complicated projects can take months and even a year from start to finish. And the worst thing is that at any point along the way, someone can pull the plug and send all of your work to the trash can.

Hackathons bring the fun back into development. In fact, only two things separate hackathons from those glorious days of hacking nights and weekend: first the theme comes from someone else. Note that I said theme and not idea. Most hackathons have a theme and guidelines which come from the sponsors, but each participant will have their own idea about how to implement. The second thing is prizes! Most hackathons give cash prizes for first and sometimes second place. The amounts of the cash range from a few hundred dollars to a million dollars. And in case you don't get the big money, most give schwag ranging from mugs and t-shirts to phone and tablets.

Hackathons are by definition short. They last any where from a few hours to a few days. Your idea goes from concept to completion quickly. Now the first confusion that many have is that the finish product is code complete and production ready. This never happens. In fact, depending on the venue, there may not be even a single line of code written. Instead hackathons are normally about the quality of your idea. Do other people get your idea and will they embrace it. The bulk of your time is spent on two things: build enough of your idea for people to get it and preparing your presentation so that people will embrace it.

All of the hackathon contestants I have ever spoke to get the first part, but many don't get the second part. In fact some are surprised that they need to prepare a presentation. But getting people to embrace your idea is key and fun part of the hackathon. 

So now you know a bit about why I like hackathons. Next time I will talk about what you should do if you want to participate in a hackathon.