

Ask HN: Hackathon tips? - djshah

A friend and I are going to spend a weekend hacking in a couple of weeks (and hopefully release something worthwhile at the end of it) and I was curious to know how most people split their time during a hackathon in terms of time spent on tasks - brainstorming, design, coding, sleep etc.<p>Also, what is the consensus on pair programming and whether it would work for a hackathon?
======
avk
I've done 2 hackathons with a large group over at UC Berkeley (sponsored by
the CS Undergraduate Association and Startup @ Berkeley) but both times worked
alone. I also did the overnight hackathon at Chirp, the Twitter Developer
conference, last month.

General tips:

\------------

\- Make sure there's enough food & drink. It's very hard to think and keep
working when you're thirsty or hungry.

\- Second monitors for everybody involved are a must.

\- Definitely still use version control. I've seen some people avoid this for
the sake of speed but the ability to try things out and quickly recover is
vital in a chaotic coding environment of a hackathon. Take the time to set it
up.

\- Don't keep things in your head for too long. It's faster to express
yourself and communicate on paper. Bring LOTS of scratch paper and pencils.

\- Take breaks unless you're in the zone. Get up, stretch out, walk around,
get food, talk with others. It'll help re-energize your thinking.

\- Don't sleep. All my hackathons were less than 24 hours and I didn't sleep.
I got a good night's rest the night before I started and I stayed away from
naps because it's very hard to wake up once you fall asleep.

\- TDD is optional. If it's part of how you already code all your projects,
keep at it. If you're not in the church of testing, don't bother. It will only
slow you down. A hackathon is not about coverage or whether your code is well-
tested, it's about whether you have code that works at all.

Splitting time:

\--------------

\- Never hesitate to stop and brainstorm, just don't let a session go on for
more than 30 minutes.

\- Leave visual design for last. My goal has always been to build something
functional, not necessarily pretty or usable. I can also crank out CSS pretty
quickly so I'm comfortable leaving most or all of the visual design for the
very end.

\- It's worth sketch out the flows early on. It will help guide and structure
your code and other ideas. Just don't obsess over a great user experience in
the beginning.

\- Spend the vast majority of your time coding. Iterate like you've never
iterated before. Hack, hack, hack, and only refactor if the latency is really
bothering you. Get to something that works first and foremost, then worry
about code quality, performance, readability, and all the things you're
supposed to when you have more time.

------
Nervetattoo
Funny you should ask about this when me and 4 others are having a hackathon
this weekend.

The plan for us so far is to use fri/sat/sun and spend aprox.. 5/10-15/5 for a
total of about 20 hours * 5 = 100. Normally you'd probably opt for longer
stretches but I want to ensure we aren't tired when monday comes.

Pair programming: Yes, if it feels right - but I'd rather call it group
programming, utilizing everyone. Sit everyone in the same room, face to face
and side by side. A ring is perfect. Have a whiteboard and papers in the room.

\-- Time plan Friday: Set up initial plan - what to build Describe initial
functionality and spend a bit of time to make a few use cases Discuss and lay
out impediments Create something like tasks for what needs to be done Hack,
hack, hack till a first iteration Replan after first iteration that solves
something - change the path?

Saturday will be all about iterating. If someone feels to brainstorm
something, do this right away unless someone is in the zone. Try to include
every one in every discussion and keep it under 10 minutes. Decide and try
fast. By the end of saturday we should have something working thats about
where we want to be.

Sunday will hopefully be for adding sugar coating and the features we thought
of during our sleep. Maybe refactor. Final touches. At the end do a summary,
get input on how we felt the hackathon went, what have we learned etc. Launch
it and blog it. \-- Time splitting We have a dedicated designer, some
dedicated backend devs and some frontend so not everyone knows the same stuff
- task delegation becomes logical and we dont have to split that much between
these tasks.

Focus on function. Design on a non completed function is worthless. A
completed function without a design is not (default browser styling) Focus on
value.

Regarding breaks I think I will try to take break whenever I'm NOT in the
zone. For a hackathon your basically not producing unless your in the zone,
you wanna be in the zone every minute you sit in front of the monitor.

------
wushupork
I've done several hackathons (DayOfMobile, iPadDevCamp) and have been involved
in judging and organizing several others (SocialDevCamp, Google Android Eco
Challenge Hackathon, I can't remember)

Hit the ground running If you already have a team and an idea, one thing you
want to do is hit the ground running. By that I mean, your project environment
should be set up, version control, templates etc. If you are wasting time
downloading and installing software that the rest of the team uses, that is
all wasted time.

Clear division of labor and expectations Nothing is worse than working on the
same thing or overlapping things in a hackathon because you just don't have
time. Also, make sure you are in agreement as to what the end points will look
like. If someone's working on the backend and returning data, make sure that
the UI developer is expecting the right payload etc. A good discussion upfront
instead of just coding right away will take care of that.

As organizer stuff you want to think about: Make sure you have decent internet
connectivity. Power strips. Food - pizza and redbull type stuff Comfy
furniture - I don't particularly like sitting at a desk hacking for 12+hours.
I might want to sit on a couch or a beanie bag. Maybe music.

I think getting people to cover the hackathon while it's going on is also a
good idea. Usually hackathons only get the spotlight when the developers
emerge from the cocoon to present. I think its great when you have people from
the event taking their flip cam and going around talking to hackers asking
what they are doing and just to see the process.

As a judge I'm always more impressed when things work. I've seen entries where
it's mostly a mockup or screenshots with no working tech. I've also seen
working tech with no UI. Obviously the more you can show, the better.

------
openfly
Tech Crunch Hackathon on Saturday in NYC I will be there.

Most important rule? Have fun. Pick a project YOU want to work on. Do it.
Doesn't have to be helpful to anyone, or even remotely sane. Just something
you are excited as hell about doing. Hackathons are meant to be fun.

Club Mate is great for staying awake. Guarana ( Antarctica ) is also great.
Coffee, and Jolt are acceptable as well.

Have some munchies. When that dead zone around 3-4 am hits it's good to just
munch on some m&ms or twizzlers. The chewing is monotonous and helps you
concentrate, and the act keeps you alert and awake.

Bring headphones. There might be times that call for a long coding stretch,
and you don't want to be disturbed. Throw on some brainless monotonous music (
such as trance or drum and base ). It'll help you tunnel vision.

Don't be afraid to screw up. You don't have to leave successful. Try to, but
don't give up on an ambitious plan just to be on the safe side. Hell you can
always finish it up a few days later and still have something awesome to show
off.

If you finish early, or during meals / breaks... talk to other people. Tell
them what you are doing, ask what they are doing. You never know you might end
up recruiting someone who can help, or tying two projects together... or just
making a good friend.

And remember, chicks dig hardware hackers. So attach some LEDs and a type R
sticker to whatever you do.

------
jhuckestein
I got hooked to hackathons recently(most notably on the winning team of the
startup bus and on stage after the chirp hackathon). Here's my advice:

50% is Smoke and Mirrors.

Usually you wont be able to release an actual product in two days. You will be
able to release something that's ingenious, adds value for some people, looks
enough like a product and is packaged so that people will try it and give you
feedback.

On coding: Don't write tests, don't review code and just go for it, be super
productive. Don't pair program (unless your goal is to solve some very
difficult problems in two days. In that case: good luck).

Finally, you'll be surprised how much can actually be achieved in two days :)

