Today I'll be speaking, mentoring, then judging at Keewi's Hack Day event.

Over a decade ago I joined a group of "hackers" in developing an open source ultra-secure UNIX operating system called OpenBSD. As the most secure OS in the world, it was designed to keep out hackers, as in crackers, those seeking unauthorized access to computer systems. But we were also hackers, a type of "artisanal" programmer. OpenBSD hackers are spread across the world and they gather themselves together periodically into one place to be super productive on a common goal over the course of several days. OpenBSD invented the hackathon, even coining the word itself.

I attended my first hackathon back when I was still in school, which I graduated from over 10 years ago. It was organized by our university's open source club, the only extracurricular activity I was involved in. We got permission to use one of the classrooms overnight and even got funding to buy a couple pizzas and pop. That was it. There were no corporate sponsors. There were no spectators watching us code except for our confused girlfriends. There were no headhunters or suits looking for geeks they could make use of. And there was no prize money because we were just there to see what hacks we could pull off in a night and then show each other.

Nowadays, hackathons are more and more common and are seen by corporations as something they can take advantage of. It's a way to recruit, a way to bring attention to new developer platforms or APIs, a way to test out ideas in a new market. But let's not forget what's in it for us hackers. Hackathons are a good way to expand our skills and hone our existing ones. It's a place to show off our programming abilities and get attention from our peers (and maybe outsiders as well). And it's a way to have a lot of fun. If you aren't having fun, you're doing it wrong.

With all that said I'm going to now give you all advice for the next 24 hours.

This is not a case competition. It's not a Startup Weekend. There are no APIs and API sponsors. Having limitations actually helps in the creative process, but this 24 hour limit is one of the few limits for this event. But otherwise it's pretty open ended so it's up to you to come up with great ideas.

1. Pick the right idea. It needs to be big enough that it's not just a feature. It should make a statement, it should say something. But it needs to be small enough to be completed in a day. Don't get arrogant (and definitely don't be arrogant during your demo). Make sure you all love the idea otherwise you won't have the energy to see it through to the end. You might come up with a way better idea halfway through and if you didn't really like the original idea then you won't want to finish.

2. Next, think of the demo. This may be all that matters. Everything you spend time on from now until judgement should be supporting your demo. Anything else is a waste of time. Don't optimize your code. Don't worry about implementing logging or authentication or paging or other quotidian things that will impress nobody. Think MVP. Implementation almost doesn't matter. Quick and dirty and nobody will be the wiser (even if we look at your code).

3. Have a plan, a schedule, and regroup often.

4. This is not the time to learn an entire new stack. Stick mostly with what you know. You don't want to realize halfway through that some unproven technology isn't going to work. Unless they are sponsoring the event or are in the audience and you're seeking funding from them. Learning new APIs and libraries and languages can turn into huge time sinks (unless they have engineers present at the event to support hackers).

5. It's never been a better time to be a programmer. With so much code available for use and perusal, so many public APIs that can be called, so much public data available, and so much hosting you can use for free. You can have featureful websites up in less than an hour with stuff like Drupal and can use stuff like Twitter Bootstrap or theme clubs like Joomlart and you don't need to be a designer anymore. So this is not the time to roll your own CMS or framework from scratch nor is it the time to tweak out over pixels. And you aren't allowed to write any code before the event (unless it's in some public repository).

One last thing. In your plan, make an allowance for the effects of sleep deprivation at the end. Expect that tiredness to shorten your tempers, affecting judgement and emotions. While drugs can counteract some of these effects, coffee can only go so far.

Want more advice? Read how to make yourself a 10x developer.