Hackathons are a great opprotunity to learn new technologies, work with different coworkers, and be a cataylst for products that may have viability. They can give a chance for you to fix your biggest issue with our current products, create great new features, or pave a new path.
All nighters should be discouraged as they skew towards younger people.
- Free-floating - a month long hackathon that can be worked on during free time
- Sprint - 2 to 3 days
Teams of up to 5 members may group together. Ideally, members with different specialities will pair up.
- Lead (Developer, Designer, or Manager)
- Designer
- Frontend Developer
- Backend Developer
Anytime before the hackathon, people can submit ideas to a Google Form for possible topics to work on. The entries into the form are open to everyone, but the original creator has first rights to the topic.
Example Categories and Topics
- Formative Focused
- Near future research and development
- New quiz format brainstorming
- POC for pursuing a feature in the app
- Implementing Synthesia
- Secondary app outside our primary one
- Class orientation
- Near future research and development
- Industry adjacent
- Interactive learning game
- Museum app for field trip education
- Open Source
- Dynamic tool for designers to prototype quickly in a staging instance of an app
- Tooling
- Self-hosted log and error tracking
When the hackathon starts, immediately after formation, each group can spend some time identifing which topic to pick and the challenges they might face. It might be unfair to do this before hand as people may be out the day before.
Before the hackathon begins, there should be both design and development starter projects ready for those who choose to use them.
Communication during development is very important in completing a POC focused and on time.
At the end of the hackathon, or the following weekday, each team is able to show off what they have built. Depending on the results of the projects, each team is able to opt in to showing off the work to the rest of the company.
Should there be judging?
A virtual high-five!
- In most cases, it doesn't matter if the source code is sloppy since it can be cleaned up later if the product is viable.
- Try to spread your team out across skillsets.
- Use a technology stack that you're familar with.
- Create multiple branches, or snapshots, for checkpoints in construction. This helps for demoing your app later.