• View
• Edit
• History
• Print

What would be the key to success for this VR Hackathon from a team organization point of view? A recipe...

FIRST, self-discipline - never forget that your brain is a muscle, and needs rest.

• sleep well before,
• eat apples (best invention to keep awake – not “energy” drinks that are just efficient half an hour, and not healthy especially when cumulated), avoid anything that is with added sugar (soda is satan)
• drink water (not beer, not coffee, but just plain water)
• from time to time, walk outside, take some fresh air (not the one smelling your feet) – solutions happen usually at that time
• take your sleeping bag (+ socks, deodorant) even if you live next door (a hackathon crystalize emotions & stress, because of all these ideas and excitement around, you sponge a lot, useless to try to sleep afterwards). New Socks after 24 hours is heaven, believe me. I ended walking bare feet at the end (no socks).
• take a shower (we are not animals – even if sometimes it’s fun to stink a bit) if you can
• do sleep – hacking overnight is stupid (especially on the first night) unless you’re having great conversations with these people who don’t sleep either and make surrealistic & plan to sleep during the day or so. If you don’t, you’ll pay it cash the day after with critical errors in your code and decision thinking.
  • No, working overnight is not an heroic act of bravery, but just a blatant lack of organization.
  • Don’t do drugs – if you were part of my team, be very discrete about it then because after the event, I’ll cut off bridges, without any hesitation. I don’t do business with junkies – they are weak & not reliable. Go away before I smash you.

SECOND, never forget it’s a team’s effort, and that’s probably the most difficult part of the game. Don’t take anything personal. Keep in mind your target: get things done on time.

• Your only objective is the following: an enjoyable experience at the end of the hackathon by the time judges will pass by. Time-management is key here.
• Make the idea, the concept as clear and focused as possible.
  • Get it prepared, ready, fun, challenging (it’s still a hackathon) and feasible within a weekend. Challenge it by yourself. This is probably the hardest point.
  • Write it on white boards, paper, puts them on the wall. But write them. If anyone has an issue, he must raise his hand quickly. Write such as you can read it back yourself.
  • Endless discussions are a loss of time (and the time is so limited), but be ready to compromise (except if it would kill the concept of the project, argue back then).
  • The idea you presented is not yours anymore. It needs to be your team’s idea. Each members need to make it his/hers. When someone has an idea, even if it was part of your plan, let him/her make it his/hers. It’s essential everyone in the group feels having a place, feels contributing. Motivation is a key factor.
• Don’t impose a PM methodology – try to find the essence of the group, and adapt the various methodologies to this group.
  • I used some Agile gimmicks, but put lots of my FPX aside.
• Listen to everyone, make sure everyone listens when someone speaks, make sure everyone is present when an idea is mentioned and gives his opinion.
  • But avoid people to repeat themselves twice. Direct then the team – the conversation being over. Avoid endless discussions at any cost. Especially when everybody is tired.
• Identify the key resources, the ones with the heaviest critical path, help them, support them.
  • make sure no noise around them. Make sure everyone is busy, has found ways to contribute. The right balance needs to be found.
  • Presence does not equal performance
• Put an atmosphere of respect, collaboration, and production (never forget the goal of your project).
• Never forget you are not expert in everything, and this event is for fun. Let the others speak.
• Organize things, not as a tyrant, but be directive enough to avoid loss of focus. Have always an initiative ready in case no-one has. Don’t especially impose yours if other propositions make sense and/or vaguely goes in your direction.
• Give leadership if someone seems convinced in a specific direction and wants it. Try to be clever with such burden. It’s about the project, not about your ego.
• Never blame, except if s(he) really piss you off. Don’t be rude, only losers are rude.

THIRD, talk to others, to your “competitors”.

Actually you compete against yourself, to increase your skills. The best way to increase your skills is to exchange. In a hackathon, only passionate people ready to spend 48 hours in front of a screen. By helping, you get to know better a project, a way to work. It really helps.

Nobody loses a hackathon, except maybe those who:

• Make their projects on their own, because they did not find any teams. There is much less exchange, better stay home and consult Stack Overflow or your twitter account
• Refuse to be part of a team because no project is good enough for their ego
• Come with a team already structured months ago and organize a safe path to win, not sharing anything with others. If having a safety net is understandable and such event could be a nice kick-off to start a project, such behavior might not be that great to other amateur in this event – especially if you take out free, skillful & valuable resources. Furthermore, where is the hack then?
• Lose their temper (control, control, discipline)
• Have ego issues, not accepting leadership, or the way things get organized

FOURTH, what about post-hackathon?

Well, it really depends on how close the team is. Be aware there will be a huge difference though;

• No more privileged immediate interactions anymore with the teammates you barely met. Emails, slacks, tweets do not change anything. Be very cautious on misunderstandings – do not hesitate to go for clarifications.
• A team for hackathon is very different to a team in a start-up. Selection & recruitment process would be clearly different. From a PM point of view, lots of decisions would not make any sense.
• Potential frustrations & deception go out, there is so much stress and control, everybody linking their personal objectives to the common one. It’s life… On the other end, this could be a fantastic opportunity – with such extreme work experience – to create an interesting base for future projects

TEAM during the Hackathon

because it’s a whole team work

Team, project, game play coordination by @Tanguyvl, supported by Clarrisa & Pedro

The whole pitch, team set-up & concept directions happened on Friday night, Tanguy continuously poundered the needs of the team and tried to keep a productive environment. Clarissa gave support on Saturday, as a tester, she relevantly challenged many of our directions. Along with Pedro who joined on Saturday and Sunday, they explored the various features of a finished product, gameplay.

Original coding from scratch by @Utopiah from the Brussels VRlab, supported by Michiel & Mohamed from the Brussels VRlab

Decision has been made on JS, since @Utopiah masters that technology. He got supported by Michiel (C++) who learned Js from scratch and Mohamed who is VR hardware designer. Since it’s a hackathon, time is unfortunately limited, the coding got structured as follows: 1) Friday night, description of the needs 2) Saturday, start of a 20 hours straight coding: iteration #1 3) Sunday, factorization, assets integration & testing for submission at 1.30pm + adding a code of a fan power depending our your bobsleigh speed

Original design from @VRFred

Because web-based, the whole environment had to be as light as possible and low-polygon (no textures). “A game for the whole family” design where nothing comes from existing libraries. A great 24 hours support from this Santa-Claus design hacker.

Original sounding from @Lamoova_didier

When boosting the Bobsleigh, Didier actually hacked the Ariane rocket sound at take-off! And this sounds great. Lots of surprises here and there that set up a whole crazy environment where a grin is the obvious outcome.

By Tanguy Vanderlinden - @tanguyvl