Notes From a First Hackathon

Why it matters now

I went in expecting to learn a framework. I came out having learned how to scope a problem down to something two people could finish before sunrise.

This is a note for anyone who has been putting off their first one because they assume everybody else already knows what they are doing.

What 36 hours actually taught me

Four lessons, roughly in the order I learned them the hard way.

The compressed curriculum

1. 1.Cut scope first. Our original idea was four features. The version that worked was one, finished.
2. 2.Demo early. We built a fake end-to-end path in hour three, then replaced pieces. It meant we always had something to show.
3. 3.Ask sooner. Two hours lost to a build error that a mentor solved in ninety seconds.
4. 4.Sleep. The team that stayed up all night shipped less than the team that took four hours off.

Pitfalls to avoid

• Building for the judges. The projects people remembered were the ones the makers obviously wanted to exist.
• Starting with the stack. We spent an hour choosing tools before we could state the problem in one sentence.
• Skipping the room. The people were the point. The project was the excuse to meet them.

Frequently asked questions

Conclusion

The code is long gone. The people I met are still the reason I know anything about this field at all.