• Eric Muyser

    "What I want for myself, I want for others" - Wallace D Wattles

    I learned a lot at my first hackathon, HackVAN. I gained some experience with the APIs presented, checked out some nice apps, met some cool people,  learned a bit of Ruby on Rails. Overall it was a great experience. If you want to check out the results, they are here. If you’re near Toronto on April 14th, you should catch the next one. :)

    If my team reads this, no offense, I’m just trying to clear my thoughts. Perhaps somebody will drop by and clear up any misconceptions on my part. The lessons are specific to my experiences and observations; perhaps arbitrary, but it’s my blog. :D


    Random quote from the API presentations:

    Dev, “I was wondering if the judges will be able to test the app on iPhone and Android?”
    Host, “I think you forgot one. Windows phones?” <looks at Microsoft rep/judge>
    Dev, “I really, really didn’t.”


    The APIs

    • YellowAPI – Turned out to be much more awesome than expected. There’s a lot of potential in this one, as we saw in the presentations.
    • TinEye – Probably one of the most obviously impressive to use. You’re analyzing images for patterns and providing relational/contextual results. It just sounds cool.
    • HootSuite – Their upcoming Engagement API is nice and simple.
    • Shopify – An elegant API. You can control nearly everything. In fact, they have a Ruby gem to setup an API operated store.
    • iQmetrix – Went unnoticed. No one took the challenge to do a mashup. (That I recall).
    • FreshBooks – Seemingly difficult to innovate, but there was a nice Dropbox-based automatic invoice synchronization solution.
    • Twilio – An obvious choice. What they do is unique, powerful, fun, and easy to show off.
    • PhoneGap – More than a few teams had the chance to utilize their web skills for their mobile ideas.


    The Lessons

    • If your team cannot work on different features in parallel, then it should be all hands on deck. Everybody should be working on getting the ball rolling. At that point everybody can switch to the stable version and move any contributions. Don’t wait for the ‘app guy’ to get something up because your features rely upon it. Just roll your own app and get something working. Don’t sit, research and plan features which may not end up getting in before the presentations.
    • If things aren’t working out: take a step back, don’t fall down the rabbit hole. Perhaps the course of action should be changed. Re-evaluate.
    • Presentations are important. Think about how you will present your project, with a focus on the question: “what problem does it solve?” If you can throw in some fancy slide shows, diagrams, graphs, or other illustrations: those go over well.
    • Never blame the API in your presentation. This is especially true when you’re presenting after people who have already shown great success using it.
    • Don’t underestimate the competition. One of my teammates was a bit overly confident. A lot of them may be younger, or less experienced, but there’s still big talent in the room. On top of that, there’s always the “X” factor.
    • Don’t convert an existing web app to use as boilerplate. I understand the appeal of being able to quickly launch your favorite environment, but it could cause more harm than good. If you have a teammate who is attempting to do this and it’s not working out, take a step back and consider writing it from scratch. Especially if it’s something like Rails, that seems fairly easy to get running (rails new + rails generate and get started).
    • Do what you know best. That may mean putting yourself and your skills out there to find a team where you can be useful. In my case, I only knew a couple Rubyists from our local meetup, but I didn’t know Ruby, Rails, or Heroku yet. Our app had no frontend UI, and was a Rails service using Heroku. But wait, I didn’t know Rails or have used Heroku. I do however have a lot of backend LAMP/Node.js, and frontend UI experience. How useful was I on the team? Not very. I should have sought out a team where I could contribute more.
    • Don’t rely upon gems. Gems are only nice if they are documented and implement proper error handling. Some don’t have one or the other, and can be a major hassle. Considering in a hackathon you may only need 1 or 2 features, such as a sending an SMS with Twilio, you don’t even need a gem/library. Just whip out cURL. In our case we had issues with the unofficial ‘twilio’ gem before using the official ‘twilio-ruby’ gem. HootSuite’s new Engagement API doesn’t have a gem yet. In reality, it was 10 simple lines of cURL to do what we needed. Copy/paste, change the endpoint/params, and you’re good to go for more.
    • You probably don’t need persistency. You’re trying to get an idea up and running. You don’t need to worry about your scalable CouchDB network right now. You can probably get away with raw arrays, but if you can get something like ActiveRecord working easily, go for it. You can scale it later, when it’s the next Twitter. ;)
    • Try not to change your project goals at the quarter or half-way mark. It’s hackathon suicide. A finished product is more important than something that could have been cool. Even if it’s not as cool as that idea you just had, you can polish it off. Judging did include the polished feel of the product.
    • Don’t go to a hackathon and port over an app you already had working with some other API, or similar. The judges will see right through it.
    • Try not to distract your teammates. If you’ve chosen a project: stick with it. Write down all your other cool ideas and bring them up at the next hackathon, or blog about them. Your time should be spent working on your agreed upon project, not thinking up and discussing new ones.
    • Don’t drink the free beer at a competition and expect to win. Unless it’s a drinking competition. I think this one is obvious. I have yet to see the mystical Balmer Peak in real life.
    • Don’t team up with people who have the same name, if you can help it, haha. ;) I was teamed up with James and James. Nevertheless, it was confusing or just distracting at times.
    • Try not to blame or insult your teammates. Again, obvious. You’re there to have fun, learn cool technology, and meet people. Playing the blame game only pisses people off. If you find any flaws in your team’s execution, blog about it afterwards. (Ahem).
    • Don’t miss out on the free swag. Big thanks to Yellow Pages and Shopify for the awesome shirts, and Twilio for the stickers!
    • Don’t eat yellow snow.

    Hopefully the next hackathon I attend will be just as interesting. ;)

    On to the next!