Last year, I had the opportunity to participate in a hackathon hosted by my university with a friend of mine. It was the first year our school ran the event, and we were surprised to walk away as winners of the “Health and Wellness” category with a wolf-themed, gamified weightlifting tracker app.
Our university hosted the event again this year, and I found myself not only having more fun, but also picking up on a few things about productivity, time management, and collaboration that I hadn’t fully appreciated the first time around.
Planning
Our university published the submission categories prior to the competition, which would have provided ample time to plan an idea, tech stack, scope, etc.
**would have**
We instead chose to play things by ear, and ended up spending the first two out of twelve hours of the event brainstorming an idea. I can now say with confidence that it’s much better to walk into an event like this knowing what you’re going to do and how you’re going to execute on it.
We settled on making a video game in Godot centered around AI-powered (LLM-driven) villagers. I had only dabbled in Godot briefly beforehand, and my partner had zero experience with the engine, so a large portion of our time was eaten up by tutorials and figuring things out from scratch. A little preparation ahead of time would have gone a long way.
Some images of our final result:
That said, I’ve worked on enough software projects to believe that the best thing you can do when learning a new piece of tech is to just jump in and get your hands dirty. Don’t stress about whether you’re writing perfectly idiomatic code, organizing your project files the right way, or optimizing every function from the start. Overthinking all of that leads to analysis paralysis, and analysis paralysis means you never actually build anything.
Time Management
Image Credit: The White Rabbit from Alice in Wonderland, a digital painting by Luz Tapia
Even after we finally got moving, my partner and I fell into another trap: spending too much time on things that didn’t really matter.
We went back and forth on the exact wording of character system prompts, debated names for our villagers, and got caught up in details that had no real bearing on whether the project would actually be functional by the end of the event.
A hackathon runs on a clock and the right approach is to identify the core features that make your project work and protect your time at all costs. Everything else is decoration. If you have time left over, then you can polish. We learned that lesson a little later than we should have, but we did learn it.
Collaboration
In spite of all of the procrastination that my teammate and I had done, we still collaborated quite well together. We focused on making decisions that aligned with getting our project done and the features implemented rather than waste any more time.
Good collaboration comes down to a couple of things. First, you need someone who isn’t afraid to tell you when you’re wrong. Second, and just as importantly, you need to be the kind of person who can actually hear that and take it to heart. There were moments where one of us had to pump the brakes on an idea the other was attached to, and being able to do that without turning it into a debate saved us real time.
Conclusion
Hackathons are a great way to stress-test your skills in a compressed, high-energy environment, and I think that’s exactly what makes them so valuable. You learn things about yourself as a developer and as a collaborator that a classroom assignment or a personal side project just doesn’t surface in the same way.
If I had to boil it down: plan before you show up, protect your time once you’re there, and make sure you’re working with someone you can be honest with. We didn’t do all of those things perfectly this year, but we did them better than last year, and that feels like the right direction to be heading. What’s more important too, is that you learn something and you have fun doing it.