How to survive a hackday
When done well hackdays can provide a perfect mix of technical experimentation and editorial nous. I regularly organise them with news organisations as part of my MA in Online Journalism; and The Times’s Build The News hackday has become an annual fixture.
So I thought I’d pull together some of the tips I gave to my students before they attended this year’s Times hackday, plus a few that they have learned themselves.
1. Decide what you want to get out of the hackday
It is easy to get caught up in what the hackday organisers want to achieve from their hackday, particularly if there are prizes on offer (see below).
But remember that it’s also about you getting something out of the day. That might be feedback from experts, an opportunity to learn new skills or make new contacts, or it might be an opportunity to really blitz some time at a project you keep putting off.
Make sure every decision before and on the day is guided by that. External recognition of any kind is nice, but you’ll ultimately walk away unrewarded if you don’t focus on your own happiness.
2. Identify what the organisers want to achieve from the hackday
That said, you’ll feel a bit of an idiot if you turn up for the day and find out that the organisers had something planned you didn’t know about.
Make sure any description of the event is read closely, and check out the organiser’s blog and Twitter accounts for other guidance.
If there are categories of project involved, or themes to explore, or datasets to use, think about how your own project relates to those. Use the limitations of the hackday as a way to look at your own ideas differently.
If there’s an expectation of competence with code, invest some time in learning that, however basic.
But remember, hackdays are not typically strict affairs, and the point is to push boundaries.
3. Don’t put too much stock in ‘winning’
Many hackdays have some sort of judging and prizes at the end. The main purpose of this is to give the day some sort of ‘closure’, and in some cases it is also a way of recruiting some of the people on the hackday (a prize might for example involve further work).
Remember what your objective was in coming to the hackday. If you achieved that, you ‘won’! Don’t rely on someone else’s very different criteria for validation.
4. Prepare raw materials and research before the day
The hackday itself is about execution. The more preparation you have made, the better the quality of that execution.
That preparation should really focus on background research, raw materials, skills and idea development rather than specific coding, designing or writing. For example:
- Know as much about your topic as possible — but be prepared to leave out most of what you find out
- Gather as much data as you can (if you will need it). Again, be prepared not to use some of it
- Collect or create other material you might need, such as original documents, images, video and audio
- Keep tweaking and reworking your ideas as you gather more information. Be prepared for your initial idea to change completely, and be brutal in asking yourself whether it does actuall solve a problem or tell a story
- Find out as much as you can about what is possible technically. Look at examples of interactivity for inspiration.
- Build any technical skills you will need
Some participants may decide to prepare the project itself before the hackday, especially if their focus is entirely on winning a prize. You’ll have to make your own decision whether that is the best use of your time and the hackday itself, but for me it defeats the object of a hackday.
5. Seek out different people
Hackdays are often about mixing people with different knowledge and skills. If teams are formed at the event itself then seek out people who are going to make you look at things differently and learn something new.
For example, when I attended the TechRaking hackday last year, I intentionally joined a team that was working in an area I hadn’t explored much before, because I wanted to learn something new. Which I did. (We happened to win, but again this wasn’t the point)
If you are taking a team to the hackday, try to have a mix in your team: if you don’t have someone who can code, then try attending a local coding meetup or contact a university computing society or department.
Remember that not all coding is the same: one person may be able to write code that gets data; another to present it; and a third to facilitate interactions with the user.
The same goes for editorially-focused members of the team: do you need someone who can analyse data? Or write? Or design? Or take photos, video or audio?
6. Relationships are important
Your team will need to work together so it’s important that you agree on your objectives early on, and an idea that everyone can buy into. Include the whole team in your communication, meetings and decision making.
Set a deadline for a final decision, and have a vote if you need to make tough decisions.
But remember that those tough decisions carry on into the hackday itself…
7. Make sure everyone has something to do
On the day itself — or before — work out what needs to be done and who can do that.
Be prepared for the idea to change as people have an input. And think about ways that different people can contribute: one person might focus on a central narrative while others focus on raw material such as data, or branches from the starting point, such as interactives, visuals or multimedia. One suitably qualified person should focus on the presentation of the idea (see below): don’t leave this till the last minute.
Set tasks throughout the day and meet as a group at particular times to review progress and set new goals.
Be prepared to compromise and sacrifice some of your ideas or contributions if it doesn’t strengthen the core idea. A flabby project is one that doesn’t leave anything out. Be lean. it’s agood sign if you are cutting things out,
8. Communicate your idea clearly
Hackdays typically involve at least one period where people have to communicate their ideas. This includes:
- At the start, aimed at the organisers
- Just after the start, aimed at fellow attendees (for example to recruit team members)
- During the event, as organisers visit different teams to find out what they’re doing
- At a midpoint, for review and feedback before continuing
- At the end, as part of a formal presentation, sometimes for judging
Different parts of the process have different demands. At the start it is key that you can communicate your idea succinctly and clearly: it should not be too complicated.
At the end, however, you need to wow your audience — especially if yours is the 10th presentation and everyone is tired.
Try to focus on what is distinctive about your idea: it will need to stand out. And focus your presentation on the visual, aural and interactivity in your project: people will be too tired to read text off a screen. Grab people’s attention, explain what problem you are solving, and what is innovative about it.
9. Justify your choices
It’s often tempting to use a technology for the sake of it, rather than because it serves the right purpose: maps are the classic example of this.
Make clear choices about technology: does it make the project more compelling, or useful? Why would this be better than a cheaper or simpler option?
10. Don’t stop when the event stops
A hackday is a good opportunity to spend a day or more on your technical development and be exposed to different people, tools and ideas, but it’s a shame if it ends there.
Make sure you finish and publish the project if you can — and write about your experiences too…
11. Be proud of what you have learned — record it
Writing about the hackday — or using video or audio — can help clarify for you what was useful about it, because at the end of an intensive day or two of work, when the sugar and caffeine are wearing off, it can be easy to feel otherwise, especially if you haven’t gained formal recognition for your work.
It can help to list the things that you have taken from the hackday: how you made your project; what new tools you have found, what new people you have met, and what skills you have developed. If another project impressed you, make sure you tell those people.
This post was first published on the Online Journalism Blog.
