A while back, Prakriti and I participated in Women Techies, a hackathon at our university organized by the Google Developer Student Clubs at VIT Vellore. Our goal was simple: reach the final pitches and present on stage. Our journey began with a flurry of ideas as Prakriti and I brainstormed potential projects. We wanted to create something impactful, something that could stand out among the plethora of brilliant concepts around us. After several rounds of discussion and plenty of coffee, we finally landed on an idea that sparked our enthusiasm. We decided to make a command line tool for developers—a project that would give us a break from developing solutions for others and allow us to create something we would actually use.
Developing a tool to solve a problem we personally faced made the process both easier and more enjoyable. Knowing the ins and outs of the issue meant we could design a solution that truly met our needs, making the project not just a task but a passion-driven venture. As usual, we started by laying out the basic blueprint of our project, refining the idea as we progressed. We carefully selected a few key features and decided on the tech stack we would use. While GoLang or Rust would have been ideal for building a CLI, we opted for JavaScript, a language we were both comfortable and proficient with. This choice allowed us to focus on delivering a robust and functional tool without the added hurdle of learning a new language under time constraints.
The hackathon began, and the clock started ticking. We jumped right into programming and quickly completed two of the easier features while also setting up the GitHub repository. Neither Prakriti nor I are big fans of frontend development, so we were relieved that this project required no Figma designs or frontend coding. This allowed us to focus entirely on the backend and functionality, which played to our strengths and made the development process more enjoyable. As Review 1 approached, we decided to stop working on newer features and instead focused our efforts on polishing and refining the ones we had already completed. Our aim was to ensure that they were not only presentable but also free of bugs. One of my favorite practices during hackathons is to create a concise document that encapsulates the essence of our idea in a few bullet points, along with bullet points on what parts of the code we have completed and what we will be working on after the review. This document serves as a handy reference for ourselves and for any potential reviewers, providing a clear overview of our progress and direction. Since reviewers do not have a lot of time on their hands and teams spend a lot of time on presentations this gives them exactly what they want to know to look at while you present.
After review 1 we hit a roadblock. We had spent too much time on trying to develop features and we were no close to completing them than we were a few hours ago.
This is where most teams in hackathons fail. Failing to build something they planned on or taking too long and not being able to complete it in the give time frame is something which we generally struggle with. Sometimes it makes sense to think of something new instead of sticking to the same thing you’ve been trying to do considering the ideating phase in hackathons is short.
We were tired, frustrated and this was when we felt like we would not achieve our goal of reaching the final pitches. We thought for some time and decided to scrap those features and started brainstorming features that we could replace them with. Now we had something to look forward to. We weren’t stuck anymore! This was around the same time when the GDSC organisers had started jamming.
We decided to add an agile tracker to our cli and a couple more features. We sat overnight and completed a major chunk of the newer features and took a small nap. After waking up with a fresh mind fueled with coffee we got back to programming. We finished the tasks with the highest priority first. Since review 2 was sneaking up on us and a requirement for it was to have a presentation we got to making that as well on the side. Our designing skills aren’t really the best so we had to get some inspiration from here and there but 30 minutes later we had a decent presentation. Review 2 went well – all of our features worked well and there seemed to be no bugs. The only part that was left was a bit of documentation. Technically speaking the hacking time was over and now we just had to wait for the results to see if we made it to the final pitches. We were pretty tired so instead of finishing the documentation we took a pizza break instead.
2 hours later the results of the top 10 teams were up. There we were on screen! The debugging ducks
made it to the final pitches!
As the second-to-last team to pitch, we had the opportunity to witness the impressive projects developed by the other teams. Each presentation showcased a unique blend of creativity, technical prowess, and innovation. One project that particularly stood out was created by a team of freshmen who had developed an augmented reality app using Unity—a remarkable achievement considering the short 36-hour time frame of the hackathon. Soon after that results were announced.
We learnt a lot from this experience. The biggest learning being that hackathons are not just about having the best programming team out there. A successful hackathon team includes skill, presence of mind, hardwork, and a good idea to begin with. Programming is just a way for you to bring your ideas to reality at a hackathon it doesn’t matter if you have the best backend if your idea is generic. An unstable/hacky solution to a real problem has a better chance at winning rather than a really well programmed generic solution.
Don’t be afraid to change things mid way and try things out, that could be the difference between making it to the final pitches and getting eliminated in the final review. In a hackathon not too long ago a team changed their entire idea mid way and still managed to win in their track.
Keep Hacking!
Be First to Comment