What Losing a Hackathon Taught Me About Code — and Myself

#programming #beginners #devops #learning

A self-reflection on my past project — DiaGuide — and what I learned about “good code”

I thought I had something good. DiaGuide — a diabetes risk prediction app I built in under 48 hours — was working. The ML model ran fast, the precision was acceptable, and the website was clean. I even added subtitles to the demo, just to cover the “accessibility” criteria.

I submitted it thinking, This could win. I imagined the approval from the judges, getting that DevPost badge, and seeing a certificate with my name on it. Every notification made me reach for my phone.

Then the winners were announced. I wasn’t on the list. I checked again, and there was nothing.

That loss hurt more than I expected. This was supposed to be a simple project that I built over the weekend for fun. Then I looked back at my project, and I was confronted by some hard truths about design, collaboration, and what “good code” actually means.

Design

The moment I opened the web page, I was greeted by a generic form design with nothing unique to offer — just a simple toggle select. Since I didn’t have much prior experience with UX/UI design or building interfaces, I used Streamlit because it integrated well with the rest of my Python ML code. However, compared to the winners’ web pages — visually polished and built with React — mine felt way too simple.

I knew this would be an issue before I even started coding, so I tried to make things more interesting by showing the form questions one at a time. But it didn’t work as I expected. There was a bug where, after I clicked “next,” the next question popped up beneath the previous one, and the old question wouldn’t disappear until I selected an answer for the new one. I decided to turn this bug into a feature, because it seemed nice at the time. But that was a mistake.

Instead of making my form page feel more unique, it just made it look buggy. In some cases, the previous question would suddenly disappear in a jarring way; in others, the new question would collapse to the top, forcing the user to move the cursor all the way up to continue.

(Here is how annoying it is: — Screen recorded by author)

Collaboration

Here’s a harsh truth I learned about building: one person cannot do everything perfectly. I soloed the whole project and did everything from front-end to ML models; I didn’t have time to perfect either, so the result felt rather incomplete.

I learned that it is important to build in teams where everyone specializes in a certain aspect of code — one person builds the ML model, another the front-end, another the back-end, etc. That way, it’s much easier to build, and the result feels complete and functional.

When I was building solo, I spent half my time switching hats — ML engineer, front-end developer, bug fixer, sysadmin. Every time I focused on one aspect, I had to completely switch gears and adapt for the other. This mental gear-shifting slowed me down significantly.

But this doesn’t happen in a team; one person can work on polishing the UI while the other fine-tunes the ML model. The pieces come together faster, and you’re not stuck in “fix everything yourself” mode. It’s less stressful, and the result feels polished.

Another important aspect of being in a team is continuous feedback. I believe one of the main reasons my project fell short is because I didn’t get feedback about how terrible my UI was. I’ll admit, it was unbearable. And I can definitely see that now. But when I was building it, it seemed perfectly fine and somewhat “original.”

The excitement of building something and the stress of trying to finish on time made me blind to my project’s weaknesses. That’s why I wish I had worked with someone else. (I actually invited somebody, but they had something come up at the last minute.)

I’ve talked all about the benefits of being in a team, but is being a solo builder that terrible? If you don’t like constantly giving updates, trying to glue every piece together, or spending hours convincing teammates to add certain features, then being solo might not be so bad.

Being a solo developer can speed up some parts of the development since you don’t lose time communicating or trying to piece everything together.

But I believe the time saved by being in a team is much more significant than the time saved by building solo.

What “Good Code” Really Means

After losing, I went back through my code and realized it was full of little details that I loved but the user would never see. I spent quite a bit of time making all the questions line up perfectly with one another, but that didn’t benefit the user at all.

I remember endlessly pressing Tab and arrow keys to fix indentation issues. But none of that was necessary.

I’ve always loved coding with great structure — everything lined up perfectly, every variable name making sense. While that’s nice for developers, including myself, it doesn’t add anything for the user.

The user doesn’t see my elegantly aligned lists or the clever Python trick I slipped in. They only care about what’s in front of them — because that’s actually what matters.

When I think about what “good code” means, I ask myself: Why do we code? What’s the purpose? It’s to build a product, maybe a service — not just to produce clean, well-organized code. Good code isn’t the end goal. It’s a tool to deliver something people find valuable.

It doesn’t make sense to complicate your code when it has minimal effect on the user’s end. I spent a significant amount of time trying to make my form viewer “original” while I could have spent all that time trying to fix the buggy transition between questions.

Looking back, that was the biggest shift in my mindset; good code isn’t about making the developer happy, it is about making the user’s life easier. I could use all the — so called — best tools in the world but if it doesn’t make a difference for the user, they are a waste of time.

The realization stung because it meant I spent my 48 hours worrying about the wrong things instead of what really matters. But it also stuck with me — and weeks later, DiaGuide still mattered to someone.

One day I got a message on my Dev.to post explaining DiaGuide. It was from someone with type 2 diabetes. They wrote that tools like DiaGuide can help people catch risk early and take action — and that it could encourage someone to take action.

It wasn’t a certificate or a DevPost badge, but it felt better. I might have lost the hackathon, but I had built something that actually mattered to someone. And that’s the real reason it’s worth putting time and effort into building tools, websites, and anything else — because they can make a difference.

I write about learning AI by building real tools, not just tutorials.