Post provided by Natalie Cooper, MEE Senior Editor

In September 2025 we ran a hackathon to collect data for a paper on data- and code-sharing across the BES journals. After the event, we thought it might be nice to share what we learned about hackathons here on the MEE blog. Massive thanks to all the participants of the BES Data and Code Hackathon for their input!

What is a hackathon?

The word “hackathon” is a portmanteau that combines the words “hacking” and “marathon”. Specifically it’s an event where people engage in rapid and collaborative programming over a relatively short period of time. Note that hacking in this context doesn’t mean we’re trying to break computer security systems, it’s another word for exploratory programming!

Hackathons were originally very “tech-bro” coded events, where a bunch of (primarily straight, white, able-bodied men) would program for 48 hours in someone’s basement fueled only by beer, pizza and toxic masculinity. These have thankfully evolved to be more inclusive in terms of participants, aims, scope and practice, and are global platforms for problem-solving and collaboration. They can be important for community building and skills sharing.

Famous hackathons include NASA’s annual “International Space Apps Challenge” [https://www.spaceappschallenge.org/] and “Random Hacks of Kindness” [https://rhok.ca/]. These events attract not only programmers but also creatives, designers etc.

There are also “datathons” where people generate, collect or evaluate data as a group rather than programming. I generally just call these hackathons too as it’s a nicer word! 

Why might you organise a hackathon?

There are also many reasons you might want to organise a hackathon, but the main reason is to achieve more than you could on your own. This could be in terms of the quantity of what you can achieve, for example if you want to write code you can write more if there are 20 people helping! But it is also important to think in terms of diversity of thought – more people means more thoughts, opinions and ideas, especially if the hackathon is attended by a diverse group. You may also want to organise a hackathon

• To solve a specific problem.
• To build community.
• To give back to the community.
• To build your organisational/leadership skills.
• To have fun!

Why might you attend a hackathon?

There are many reasons you might want to attend a hackathon, but I think they can be summed up as follows.

• To gain specific skills in the topic of the hackathon.
• To develop skills like problem solving, critical thinking, creativity, team work, communication and time management.
• To expand your network.
• Be part of a community.
• To give back to the community.
• To have fun!

How do you organise a hackathon?

Now we get into the tricky bit! How do you organise a hackathon? There’s no one-size-fits-all approach, but I tend to roughly follow this outline.

1. Gather your core organisational team
2. Decide on your aims/goals
3. Create a protocol/guidance document(s)
4. Review and test the protocol/guidance document(s)
5. Plan event practicalities
6. Attract/invite participants, share information with them
7. Run the hackathon
8. Update participants and evaluate
9. Finally…achieve your aims! 

Some parts of this are fairly obvious, but let’s go through them one at a time. I provide an example from the BES Data and Code Hackathon in my next blog post [link].

1. Gather your core organisational team

Before you start, decide who your core team organisational should be. Make sure you have all required skills covered, and always consider participant diversity. The core team shouldn’t be too large or it becomes hard to make decisions, but you can ask others for their opinions as you go. Decide how to delegate tasks and start planning!

2. Decide on your aims/goals

This is really important. You could do this at the hackathon if the group will be small enough for everyone to contribute (see considerations below). Otherwise it’s good to decide before you advertise the event.

First, generally consider what you personally want to get out of the hackathon. As early career scientists it is sensible to ensure you will get something (other than stress!) out of organising any event. Perhaps you want to gain new skills, or experience for your CV? Perhaps you want to build community? Or perhaps you want to solve a specific problem or produce a specific output? At the same time, consider what you want participants to get out of the hackathon. It’s never OK to exploit people, so ensure they will also gain something; this could be skills, training, community engagement, or a specific output their name will be on, like a report or a paper.

Next, develop the specific goals or aims of the hackathon. These will be influenced by several factors, which will also influence your goals and aims. Some important considerations are:

1. How many participants do you want at your hackathon? Small groups can interact more and have more individual input to the process. However, you then might need to limit numbers meaning people are left out, and your goals may need to be less ambitious. Larger groups ensure no-one is excluded but can be harder to manage. Larger groups can also get more done and allow for more ambitious goals.
2. Do you want to run your hackathon online/in-person/hybrid? In-person allows for more interaction and is a better experience for attendees, however, it is also more expensive as you might need to pay for venue hire, food etc. and can restrict attendance. Online means everyone can attend, regardless of location, disability, other responsibilities, or resources. It can be difficult to achieve a sense of community at online events, and they require tech solutions to solve this problem. The final option is hybrid, which is the best and worst of both worlds!
3. What skill-level participants do you want at your hackathon? A mixture of skill levels allows for mentoring and growth. Less skilled participants will need support, and may restrict the ambition of goals. Advanced attendees allow you to spend less time on training/mentoring and more time making progress and thus more ambitious goals. However, advanced attendees may be harder to attract to a hackathon. It also depends on the community you are trying to build.
4. How long do you want the hackathon to be? Traditionally these are short 1-2 day events which makes sense for in-person events where people might need to travel to the venue. But for an online hackathon you could go for a week, or longer with specific times for interaction, e.g. once a week. The longer the hackathon the more you can get done, but there is the risk of declining engagement over time.

Once you have worked through these considerations it is a good idea to clearly and concisely state your specific goals/aims for the hackathon, along with the less specific ones like building community. 

3. Create a protocol/guidance document(s)

These documents will inform participants about the goals/aims of the hackathon and any other key information they need to participate. At the simple end this could be a very simple list of ideas for what they might work on during the hackathon along with any bounds or requirements. For example if you are developing apps, who should the end users be? At the more complex end, these documents might include a detailed protocol for data collection along with data entry forms etc. Remember to consider GDPR compliance if storing names, emails etc.

4. Review and test protocol/guidance document(s)

No matter how clear you think your instructions are, there will always be room for improvement. Ensure your protocol/guidance documents are reviewed and tested first by the core organising team, then externals of various skill-levels, and finally the participants themselves. Ask for any comments a minimum of 1 week before the event so these changes can be incorporated. See [link to next blogpost] for the story behind why I give this advice!

5. Plan the event practicalities

These considerations should be standard for any kind of event but for completeness…

At in-person hackathons, book a room with enough space, plug sockets (and/or extension cables), and access to bathrooms and water. Remember to order teas/coffees and lunch in advance (or tell people where to get their own). Make sure the WiFi is strong and works for the number of people attending, and that you have log in details for guests if required. Always remember to consider accessibility, including prayer rooms, lactation rooms, quiet spaces, accessibility of the space, and dietary requirements.

For online or hybrid hackathons, think about how to make the hackathon more interactive. How can attendees communicate? How will they ask questions? We’ve used Discord and Slack for this in the past. Organise online coffee and lunch breaks where attendees can video chat if they want to. For hybrid meetings, consider how you will ensure an equally good experience for online attendees. How will online/in person attendees interact? I recommend having a dedicated online organiser who will take care of online attendees if you are running a hybrid event.

For both in-person and online events you must have a code of conduct (e.g. https://www.britishecologicalsociety.org/content/code-of-conduct/). Make sure this and all relevant information is shared with attendees in a timely manner.

6. Attract/invite participants, share information with them

Share it wherever you can! Mailing lists and socials are a good plan. MEE are happy to share events on our socials! You could also contact an appropriate BES Special Interest Group [https://www.britishecologicalsociety.org/membership-community/special-interest-groups/] to ask adverts to be sent round their mailing list. You might need to target specific people if you have a specific aim that requires certain skills.

7. Run the hackathon

This is the fun bit…turn up, program, chat, drink coffee, immerse yourself in the unique chaos of a hackathon. But remember to check everyone feels happy and included, and knows where to find the emergency exits/toilets/coffee etc. 

8. Update participants and evaluate

It’s easy to run a hackathon and then just move on with your life. But that probably won’t achieve your goals! It’s important to evaluate what worked and what didn’t as soon as you can after the event. Don’t forget to update the participants on next steps, and delegate any activities needed to make the goals a reality, and continue to push these forwards until…

9. Finally…achieve your aims! 

Note that this will be easier for some goals than others. If you aimed to build community, maybe it doesn’t matter if you didn’t write a paper but you had great interactions. Be realistic and kind to yourself and your busy schedule. If you won’t meet an output goal make sure to update your participants.

Criticism of hackathons

Before ending this post I think it’s important to quickly cover some of the criticisms of hackathons. 

First, hackathons may be ineffective for long-term solutions. One study found that of 11,889 hackathon events in the USA, only 7% of projects had any activity six months after the hackathon. I think a key issue is that it is really hard to “finish” anything in a short period of time; it requires follow-up after the event which can be hard to engage participants (and organisers) in. A solution here is to make it clear who is in charge of follow-up after an event, and ensure that follow-up happens!

Second, hackathons use unpaid labour, so can be exploitative. This is particularly an issue when the hackathon is for designing products a company will sell. In academic circles, hackathons use the time and effort of unpaid early career researchers to create outputs that may not benefit them. If you organise a hackathon, ensure the participants gain what they expected to and, it should go without saying, do not exploit people!