I Loved the Hackathon. The Pull Requests Came After.

I loved the hackathon. Not because every hour went perfectly, and not because I left with some perfect origin story. I loved the feeling of being around people who were willing to turn a rough idea into something real while the clock was running.

The event I am reflecting on is Gemini Hack Kigali, an MLH-powered, one-day, in-person hackathon in Kigali, Rwanda. This is a general reflection on the experience, not a project submission. I wanted to write down what stayed with me after the demos ended.

The part I did not expect

The demo is the part everyone expects to remember. For me, the bigger takeaway was the habit that formed around it.

Hackathons compress a lot of decisions into a small window. You have to choose a problem, make a small thing work, explain it clearly, and listen when someone sees a flaw you missed. The pace is uncomfortable. It is also useful.

What I carried forward was simple:

• Pick a problem that is real enough to care about.
• Make the smallest useful version work.
• Ask for feedback before polishing the edges.
• Keep going after the event ends.

That last point became the bridge between the hackathon floor and my open-source work.

The work continued after the weekend

After the event, I kept showing up for small problems in other people's repositories. A broken edge case. A confusing error message. A missing test. A path that failed on Windows. These are not glamorous problems, but they are the kind of work that makes software easier for the next person.

At the time of writing, GitHub's live search reports 764 merged pull requests authored by aniruddhaadak80. I am including the live search link so the number can be checked instead of taken on faith. The total includes repositories I own, so I am not presenting it as a purity contest. The examples below are merges into external repositories.

The latest batch

The latest batch I checked had merged between September 24 and September 25, 2026:

Repository	Pull request	What changed
genspark-ai/genoffice	#838	Bounded SmartArt fallback depth
genspark-ai/genoffice	#832	Replaced an empty notes master list
genspark-ai/genoffice	#868	Capped Gemini streamed tool calls
genspark-ai/genoffice	#867	Paginated cloud project cache checks
genspark-ai/genoffice	#871	Bounded logarithmic chart bases
genspark-ai/genoffice	#831	Parsed layout geometry independently of order
genspark-ai/genoffice	#835	Avoided unsafe relationship ID arithmetic
genspark-ai/genoffice	#833	Failed closed on malformed protection salts
genspark-ai/genoffice	#870	Contained exported image paths
genspark-ai/genoffice	#837	Indexed double-draw candidate pairs
github/docs	#46058	Updated an operator token link
github/docs	#46055	Updated an artifact retention link
github/docs	#46050	Clarified classroom clone directory wording

Looking at that list, the changes look small from the outside. That is exactly why I value them. A maintainer has to trust the change, not just the idea behind it. Most useful contributions are not dramatic. They make a system behave the way somebody already expected it to behave.

The first external merge is not the important part. The loop is:

1. Find a real problem.
2. Reproduce it and explain the failure clearly.
3. Make a focused change.
4. Accept the review, including the parts I did not expect.
5. Move to the next problem.

A hackathon gives you a deadline for starting. Open source gives you a reason to keep going after the deadline disappears.

What MLH changed for me

MLH gave me energy. The community gave me momentum. Open source gave both of those things a structure.

I stopped thinking of a hackathon as a one-day performance. I started thinking of it as practice for showing up, learning in public, and making useful things with imperfect information. The demo matters, but the habit matters longer.

The people were my favorite part. It is easy to enjoy a hackathon when you are building with friends or mentors who make the room feel generous. You exchange ideas, borrow each other's language, and discover that a problem you thought was yours is probably somebody else's problem too.

That feeling is what I wanted to preserve here. Not a victory lap. Just a real note from someone who genuinely enjoyed the event and kept going because of it.

My honest takeaway

If you are thinking about joining a hackathon, go. You may not build the product you imagined. You may spend half the day fixing something that looked simple in your notes. You may leave with a smaller scope than you started with.

You may also leave with people you want to build alongside, a clearer sense of what you enjoy making, and enough momentum to start the next thing.

That is more than enough for me.

If you want to see the work that continued after the weekend, my GitHub profile and merged pull-request search are the best places to start. You can also find me on X, LinkedIn, and DEV.

Thanks for reading. And if you have been to an MLH event, I would love to hear what stayed with you after the lights came up.