šŸ§  Top 5 Lessons Learned from Competing in Hackathons and Dev Challenges šŸ’»ā³

Key takeaways from hackathons and dev challenges, highlighting learning, teamwork, and growth under tight deadlines.

Published:

10 min read

Developers coding with a clock and programming icons in the background.

Introduction

Over the course of this year, Iā€™ve competed in three dev.to challenges and the Cerebral Beach Hackathon. My dev challenge submissions were:

  1. Effortless Image Tag Generation: Streamline Your Workflow with Pinata and IPFS.
  2. Email Buddy: An LLM-Enhanced Inbox.
  3. MelodyLink: A Social Media App for Music Producers.

For Cerebral Beach, I was part of a team and our project was called Breakdown AI which was an app designed to help people breakdown the learning process for software development into smaller pieces.

Picture this: Three dev challenges, one hackathon, and countless cups of coffee later, Iā€™ve emerged with battle scars and insights that no tutorial could teach. While I havenā€™t clinched that elusive first place (yet!), Iā€™ve gained something even more valuable ā€“ real-world experience in the pressure cooker of competitive development.

1. Time Constraints Drive Focused Innovation

Ever tried to build a full-stack app while watching the clock tick down like a time bomb? Thatā€™s hackathon life. The relentless countdown forces you to make snap decisions and ruthlessly prioritize features ā€“ itā€™s basically the extreme sports of programming. Time constraints force you to prioritize core features and push out an MVP fast.

I learned this lesson early on with MelodyLink. Even though I had experience with Amplify, I spent too much time thinking about all the features I could add and hyperfixating on little details. In the end, I ended up with a very bare bones MVP, but I couldā€™ve had a more complete app if Iā€™d spent less time thinking and more time building.

What I learned from MelodyLink, I tried to apply to EmailBuddy. Ultimately, EmailBuddy succumbed to a different problem which was scope creep. In my attempt to build a complete email inbox, I lost sight of the goal of the hackathon. However, ImageThing offered an opportunity to learn from those mistakes. I was under even more of a time crunch with this project due to Cerebral Beach starting before the Pinata challenge ended.

While working on ImageThing, I was mindful to make decisions and stick with them. For example, I ditched Bulma on the frontend and opted for shadcn/ui. I also leaned a little more heavily on generative AI for speeding up coding than I had in the previous challenges. My goal was speed, and I was able to get a clean, complete app built much quicker than in the previous challenges. Hereā€™s what I ended up with:

Screenshot of ImageThing showing the main dashboard

While the app is very simple, I am happy with how it came out. Iā€™m much happier with a simple, finished app than a complex and unfinished one.

2. Growth Over Winning: Success is Measured in Skills

Winning isnā€™t the only marker of successā€”hackathons are about growth, learning, and pushing yourself outside your comfort zone. Each challenge became my personal coding gym, where instead of lifting weights, I was bench-pressing new frameworks and doing technical skill supersets. Hereā€™s my developer gains report:

  • Frontend Development:
    • React with NextJS
    • shadcn/ui components
    • Tailwind CSS styling
  • Backend & Data:
    • Postgres databases
    • Supabase platform
    • AWS Amplify
  • API Integrations:
    • Pinata
    • Nylas
    • OpenAI

šŸŽØ Frontend Journey

Through MelodyLink and EmailBuddy, I realized Bulma has some drawbacks. While I really like Bulma, I found that making some components could be overly time consuming when trying to use generative AI. I think because Bulma is just CSS classes, the generative AI tools tend to favor completely rewriting components. Whereas using shadcn/ui, the components are more easily encapsulated in separate files. I think because of this structure, generative AI tools are more easily able to maintain consistency and not get confused when making modifications.

Another benefit of shadcn/ui is there seems to be more code examples available online for niche components. In the case of EmailBuddy, I saw the shadcn/ui website even has an inbox example.

Tangentially, I also think using components instead of classes is more easily scannable. Hereā€™s a quick example:

<{/* Bulma classes */}>
<div className="card">
  <div className="card-content">...</div>
</div>

<{/* shadcn/ui components */}>
<Card>
  <CardContent>...</CardContent>
</Card>

šŸ”§ Backend Evolution

Across all these projects, Iā€™ve found NextJS provides a stable foundation for building on. The framework itself is quite mature and the documentation for it is quite good. So itā€™s hard to get stuck on a problem for too long.

With ImageThing, I turned to Supabase and was quickly impressed with how easy it was to implement user authentication and data storage. In comparison to AWS Amplify, I felt like it was much easier to get what I wanted, faster.

Additionally, I was able to practice collaboration by joining up with some friends to compete in the Cerebral Beach hackathon. Furthermore, the skills I gained working on the dev challenges was useful going into the hackathon. We ended up building a NextJS app with shadcn/ui, Supabase, and OpenAI.

3. Sometimes You Have to Ignore Best Practices

Letā€™s be real ā€“ your perfectly crafted Git commit messages and comprehensive test coverage arenā€™t going to win you any hackathon medals. Sometimes youā€™ve got to channel your inner cowboy coder (temporarily!) and embrace the chaos. Itā€™s like building a race car ā€“ during the race isnā€™t the time to polish the hood ornament.

While working on the dev challenges, I quickly realized that writing unit tests would need to be an afterthought. When building a complete app under such a short deadline, every minute counts. As someone with a full time job, I further had my time constrained leaving me only the evenings to work on my submissions.

Unit tests can be useful for ensuring an app is still working after making significant changes, but in a hackathon the entire app might be rewritten in the early stages. Planning can help mitigate the need for rewrites, but it can be difficult to plan around technology one is not familiar with. For example, one might want to develop a specific feature and later find the technology needed for the hackathon/challenge doesnā€™t provide a straightforward path to achieve it. I ran into this problem with AWS Amplify when I struggled to figure out how to let users have a display name.

Another ā€œbest practiceā€ Iā€™ve found can be ignored is branching strategies. While working solo I quickly realized it would be easier to just commit directly to main. Trying to utilize complex branching strategies can require some effort to set up, and they also require some level of mental energy to follow. Furthermore, branching strategies are more useful when youā€™re doing multiple tasks in parallel.

Conversely, Iā€™ve found it easier to keep things as simple as possible when hacking. This even extended to the group hackathon where we all ended up committing directly to main. Early on we tried to develop one feature on a separate branch, but found integrating the changes later took up extra time.

4. Adaptability and Rapid Learning are Key

Hackathons demand you to adapt quickly and learn on the fly, whether itā€™s mastering a new framework, API, or design approach. Thereā€™s little time for perfectionism, and you have to be comfortable with diving into unfamiliar territory.

During the Cerebral Beach hackathon, our team had to quickly adapt right from the get-go when deciding on the objective of our project. Several ideas were thrown around, but ultimately we were able to come to a common understanding of what weā€™d be building. However, several team members had to pick adapt to new technology like NextJS and OpenAIā€™s APIs. Post-hackathon, some team members have continued to iterate on the idea and take the project in a completely new direction while expanding skills in different areas.

I also experienced this with MelodyLink when learning how AWS Amplify gen 2 does authentication. Some key strategies Iā€™ve developed for rapid learning include:

  • Finding community Discord servers.
  • Looking at documentation and code examples.
  • Looking for articles written by experts.

For existing technology, one might also be able to turn to chatbots. Code generation tools seem to have better outputs when youā€™re working with established libraries, frameworks, and APIs. However, new technology like Amplify gen 2 might not be something ChatGPT can help with since it will be untrained on the new information.

5. Presentation and Storytelling Matter

No matter how brilliant your solution is, the way you present it plays a huge role in its success. A great hackathon pitch or a well-written blog post on dev.to can make all the difference in how your project is received.

For my dev.to submissions, I learned that technical excellence alone isnā€™t enough. Hereā€™s what worked well:

  • Starting posts with a clear problem statement.
  • Including screenshots and demos.
  • Breaking down technical concepts into digestible pieces.

During the Cerebral Beach hackathon, our team decided to go with a simple video demo.

In all cases, I noticed that winning projects usually had well developed presentations. If not a well written post, a slide show presentation, voice over narratives, or live demos all work together to highlight the strengths of the submission.

Bonus: Tools For Rapid Development

As an extra tip beyond the five key lessons above, I wanted to share the specific tools that have proven most valuable across these challenges. From working on these projects, Iā€™ve found these tools to be the most well suited for rapid development:

  1. VSCode as the IDE when working with TypeScript, React, etcetera. Coming from IntelliJ, I have a plugin installed to give me the same keybindings. This further allows me to maintain productivity and have a familiar workflow.
  2. shadcn/ui for rapid component creation. Having worked with various frontend styling frameworks like Bootstrap and Bulma, shadcn/ui seems to provide the best solutions when coding with an AI assistant. For whatever reason, Iā€™m seeing AI is particular adept at generating shadcn/ui-based components. Usually, the only thing I have to change is the import paths. Perhaps this is because the components tend to be isolated to their own files so the scope is limited? šŸ¤”
  3. Supabase is excellent for providing a quick database and authentication setup. It has a generous free tier and also has object storage.
  4. ChatGPT and Claude are also helpful, but for different tasks. Iā€™ve noticed Claude is better at generating text for more creative-oriented tasks like iterating on contest ideas. However, ChatGPT has internet access so it can be easily informed of more current information without having to copy/paste. Furthermore, ChatGPTā€™s reasoning capabilities in the o1-preview model are useful for helping to solve moderately complex problems.

As a side note on the AI, itā€™s not a guaranteed solution. In fact, during the Cerebral Beach hackathon, the internet was spotty. There were periods of time where the internet was too slow to use until later in the day when the organizers fixed the network problems. During the slow times, it was important to rely on knowledge the team already had. If we had been just relying on AI, we probably wouldnā€™t have been able to complete the hackathon.

Conclusion

Looking back on my journey through multiple dev challenges and the Cerebral Beach Hackathon, the most valuable lesson has been that success isnā€™t just about the final productā€”itā€™s about the growth that happens under pressure. While I havenā€™t clinched a win yet, each challenge has sharpened my technical skills, improved my decision-making, and taught me to balance perfectionism with pragmatism.

These experiences have transformed how I approach software development, even in my day-to-day work. Iā€™ve learned to make faster decisions, focus on core functionality first, and adapt quickly to new challenges. Most importantly, Iā€™ve discovered that the hackathon mindsetā€”embracing constraints, learning rapidly, and building with purpose can supercharge your growth as a developer.

Whether youā€™re considering your first hackathon or youā€™re a seasoned participant, remember that every challenge is an opportunity to learn, connect, and create something meaningful. Donā€™t let the fear of not winning hold you back. Jump in, build fast, learn constantly, and most importantlyā€”enjoy the process. See you at the next challenge! šŸš€


profile

Welcome to my blog! I am a software engineer based in Southern California, and I love sharing my thoughts and experiences about all things tech. From software development and programming to the latest tech trends and news, youā€™ll find it all here on my blog. Follow along to stay up to date and get insights from a real-life software engineer living and working in SoCal. Thanks for visiting!

New post!

šŸ§  Top 5 Lessons Learned from Competing in Hackathons and Dev Challenges šŸ’»ā³

Click here to read more!