Last year, I took part in a two day hackathon where the majority of the team was made up of first time programmers. This team was made up of 3 engineers including myself, and seven programming newbies from different areas of the company ranging from Customer Support to Business Analysis.
The plan was to rebuild the core flow of our website, but giving it a 90’s face lift, including every 90’s and 00’s website stereotype we could think of. I’m particularly proud of the 404 page https://property-website-1999.herokuapp.com/404
Plan Of Action
I’ll be honest… I found the prospect of leading a hackathon of ten people pretty scary! The biggest team of coders I had hacked with prior to that was four. I had also never done a hackathon which involved non-engineers wanting to take part in the coding.
After the initial terror of the situation I was in, my thoughts quickly turned to what I could do to make this succeed. Two days for a hackathon isn’t as long as you’d think but I felt that as long as we prepared properly, we could do something really cool.
Understand Your Team
Before even getting to code, have a chat with your team and get an idea of what their motivations are for joining the hackathon and what skill levels you’re working with. Don’t make assumptions about anyone’s technical abilities. It turns out that a number of people had either done html and css courses in their spare time or had gone on paid for courses.
- Is there anything in particular that you wanted to get out of the hackathon? e.g. better understanding of what the engineering teams do
- And similarly is there anything in particular that you wanted to learn? e.g. html js, css
- How familiar are you already with any of the above subjects?
Setting Expectations (What are we building?)
With this many people new to coding, setting boundaries on the project was more important than in most hacks.
- What languages and frameworks will you use?
- What tech are you going to avoid?
in terms of splitting up the work, I decided on an approach where we would create four separate pages which comprised the core flow of the website. We would then break off into teams of two or three to tackle each page individually. i.e home page team, search results page team etc.
We created an ideas trello board where we would all vote on our ideas and vote on the ones we definitely wanted to do. Nothing too special here, just a bit of prioritisation and categorisation.
This somewhat fits into expectations but along with seven programming newbs, we also had two experienced front end engineers on the team. One thing to make clear to them is that although they would be doing a lot of cool and wacky stuff, they would also need to help me with the pairing and teaching of the other people in the team. In my case the engineers on my team were completely fine, but it is worth bringing something like this up quite early.
Set Up A Skeleton Project
In past hackathons I’ve been the victim of losing half a day just trying to get a basic hello world project working. So we decided to try and avoid that by creating a skeleton project.
We went as far as pairing during lunch to create a basic hello world express app that rendered a hello world page. Its not the most difficult thing to do but definitely made me feel less nervous on the day!
I have to say if there is one question that kept me awake at night it was how are ten people supposed to code on the same code base at the same time?
I know what you’re going to say, “just use git”. To me, git had too much of a learning curve for a two day period. I wanted people to learn how to write code, not how to do a git rebase.
Enter Visual Studio Code and its live share extension. This let us effortlessly share code and pair. It’s not overstating that without a feature like Live Share, the Hackathon would not have succeeded with that many people.
🗒 It’s worth noting that this hackathon was last year so was all in person pairing. If this was remote, then I would probably use something like a long running zoom meeting.
And that’s all I’ve got. I thought this hackathon was going to be such a stressful experience and I was so happy (and surprised!) that it ended up being a great time where we actually ended up doing more than I expected. I attribute some of this to the points mentioned above, but even more so, I attribute it to working with an awesome group of people who just wanted to learn and build something cool!
As a reward for getting this far in the article, below is a link to the project in action and a link to the project which is still up on Heroku.
WARNING! There are many many flashing lights and sounds in the link and gifs below. If you have any sensitivity to flashing lights, don’t scroll any further! I warned you…
See the project in all its glory: