Edited by Shaquil, 07 August 2015 - 06:50 AM.
Jump to content
Posted 05 March 2013 - 10:31 AM
I have done 1 coding jam in the past, last year i attended toJam(72 hours to build a game based on a particular theme).
here's some things i took away:
1. Make sure your entire team is able to contribute(one of our team members simply should not have been their.)
2. Do your best to have a design in mind. (and make sure every team member is clear on what you/they are doing)
3. Do not allow feature creep to affect you, be very clear on what you want to achieve before going there.(This one is incredibly important for your time-scale.)
4. Know your limits, understand what you are able to do, 24 hours is very little time, and be vocal if you have any sort of problems.
5. Don't include people that won't be able to contribute(in our project, sound was simply the last thing to get around to, and unfortunately the team member that was tasked with audio wasn't able to do anything.)
6. Be very vocal if something is not going to work, if you can tell it'll take to long to implement it, cross it off your list right their.
A few of these points can be taken with a grain of salt, depending on how serious you want to take this. (i.e 1 and 5 can be ignored if you just care about having a good time.)
Personally, I was lead programmer(but not team lead) for a team of five, we suffered from feature creep(something i should have been more vocal about, when you are 2 days in, and someone says "Hey, let's add that!", you should say "No."). The person i was doing this with(our team lead), was too interested in entertaining everyone's ideas, and the game became too bloated to complete in our time-frame.
We had 2 programmers, an artist, and a sound guy, and the last guy simply should not have been their. (He was tasked with making the levels, but wasn't able to learn the level editor he was given, and the levels suffered greatly because of this(practically ignoring some of the mechanics we had built into the game, it became just a generic platformer.)
Their were so many problems(and a ton of stress), that it put me off from doing anymore of these jams.
Edited by slicer4ever, 05 March 2013 - 10:34 AM.
Posted 05 March 2013 - 03:04 PM
I haven't been to many hackathons, but I've worked on a number of high-time-pressure projects with multiple participants. Here's my 2 cents...
Ahead of time:
On the day:
Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]
Posted 06 March 2013 - 09:28 AM
While not advice on managing developers exactly... I do have some advice on winning hackathons. Having been to a number of hackathons in the last year, I recommend:
1. Have a strong understanding of the judging criteria.
Hackathons are different and have different objectives. Some are to create something akin to a mini-startup where they want to see customer development done as well as some market research. Fewer are pure technical build cool shit. It's very important to know which you're going to as the strategy for each should be different.
2. Cyber stalk the judges.
If they are investors, what sort of things have they invested in? If they run a company, what does it do? See if you can find out what their hobbies are and make an app relevant to them.
3. Focus on the pitch before writing any code.
As developers we have a tendency to want to jump right in and start hacking away at something cool, but chances are if you take that approach, you will only be demonstrating a small piece of what you've built. Instead, decide what features you need to support your pitch, and build those out first.
4. Polish, polish, polish.
This means the technical components you will be demonstrating as well as the pitch itself. Run through your pitch multiple times, and make sure to leave yourself about a 30 second buffer. That means if you have 5 minutes to pitch, only develop a 4 minute and 30 second pitch. You will inevitably run a bit long during the live pitch and you don't want to be cut off before finishing your message.
5. Have a backup plan.
Internet connections fail. Bluetooth connections fail. If something can go wrong, it will go wrong on the stage in front of everyone. I watched a company presenting at launch yesterday crash and burn because they couldn't establish bluetooth connections for their demo in front of thousands of people. They should have faked it, and no one would have known that it wasn't actually using bluetooth connections! This also means if you build a website, you should probably be having a copy running locally to demo in case you cannot get to the internet. Same with services you rely on. Mock them up if you can.