Skip to content
Branch: master
Find file History
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Permalink
Type Name Latest commit message Commit time
..
Failed to load latest commit information.
How To Take Second Place at a Hackathon.odp
How To Take Second Place at a Hackathon.ppt
README.md

README.md

How To Take Second Place at a Hackathon

A fifteen minute pump-you-up talk on how to perform well at a hackathon, codejam, buildoff, or startup weekend. Tactical advice from a veteran of these types of events on how focus, finish and place well in an intensive limited-time creative competition.

Outline

  • Intro
    • So, here you are
    • A sunny weekend in {{City}} and you are sacrificing sleep, sanity and your social life to the holy altar of enterprise and creativity in an intensive limited time competition
    • You're my kind of people
    • And as my kind of people, you hate to lose.
    • And why not? Losing stinks like a bag of rotten hot dogs
    • You're here to bring the thunder, deliver the pain, and open up a can of code-driven whoopass and take home the gold
    • Well, this talk won't help you with that
    • This talk will help you take second place at a hackathon
    • This talk will help you get the most out of your hackathon experience and have a blast while building something you love
  • Bio
    • Developer evangelist for Twilio
    • Technical background
    • Though there is some debate, the hackathon that started this craze was back in 2006
    • Since then I've been to a whole bunch
    • And placed in quite a few
    • I've learned a few things about how to approach these things and am happy to share that experience with you
  • First Place at a Hackathon
    • Wanna take first prize?
    • Easy - just cheat
      • Prepare something ahead of time
      • Bring in a ringer
      • Bribe the judges {{show their pictures}}
  • Second Place at a Hackathon
    • Second place is a lot harder to win
    • Second place requires
      • Talent
      • Teamwork
      • Commitment
      • Luck
    • Second place requires all the ingredients that make a good startup
    • These types of competitions are great crucibles for forging the character of your company
  • Real solutions for real hackathons
    • Well, thanks Rob. Like we didn't know that
    • Here is some real tactical, pragmatic advice for participating in this event
    • Go With What You Know
      • Use only tools, techniques, technologies and frameworks with which you possess intimate familiarity
      • This advice goes equally for technical and non-technical team members
      • A competition like this is a poor environment to learn Django for the first time
      • Similarly, if you've been dying to do responsive design, you may want to wait for a different opportunity where the time limit is so extreme. This will only be showing up on one laptop or mobile device
      • Not steeped in regression analysis? Someone in the crowd is going to ask why you went with a linear regression instead of a nonparametric technique
      • Hackathons are not the place to "fake it til you make it"
    • Get to the Demo ASAP
      • You're not building a web service, you're not building a prototype of a web service, you're building a demo of a web service
      • You have two effective minutes to demonstrate this
      • Feature richness is not important here, feature quality is
      • Iteration is more important than a feature checklist
      • No demo == DNF
    • Avoid Common Technical Pitfalls
      • Oauth
        • Only use it for a service you already have in production
        • None of them are the same - if you know Facebook and Twitter, you're a highly valuable resource
        • Apigee is a lifesaver here
      • Users
        • Put it off if you can
        • Pick a framework that has users built in (Django, Rails, Zend, Google App Engine)
        • Don't make your own users to satisfy a framework preference (Flask, Sinatra, CodeIgniter)
      • "Well, it was running on my laptop"
        • Pick your deployment option early
        • Heroku, dot Cloud, GAE great
        • EC2 is a bigger hassle, make sure you have experience
        • Deploy frequently with non-technical team members serving as testers
    • Remember the Goal
      • There should be two - and only two - products of this weekend: your vision and your demo
      • Each should reinforce the other
      • Vision
        • Defined problem with a solution
        • Sell the philosophy, not the market or the model
        • The view with the naked eye, preferably lifted to the stars
        • Humor wins hackathons
      • Demo
        • Rehearse, rehearse, rehearse
        • Do one thing - and only one thing - well
        • That one thing should represent the obvious utility of that philosophy
        • Code freeze 9am day of the demo
        • Rehearse, rehearse, rehearse
      • Shit you should avoid
        • About page
        • Excel forecast
        • Name-dropping investors
        • Google Analytics graph
        • Intro videos *unless they are truly epic
  • Conclusions
    • Boil down your weekend to five minutes of awesome without pause
    • Do one thing and do it well
    • Having fun is the best way to ensure success
    • And hey, if you lose, you're in pretty good company

References

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.