Ask HN: Hackathon tips?
Also, what is the consensus on pair programming and whether it would work for a hackathon?
Also, what is the consensus on pair programming and whether it would work for a hackathon?
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.
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.
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.
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.
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 :)