What Six Weeks of GSoC Have Taught Me 🚀

"I came into GSoC thinking I'd spend most of my time writing code. Six weeks later, I realized that's only a small part of the journey."

A few days ago, I successfully passed my Google Summer of Code 2026 midterm evaluation 🎉 and it felt like the perfect time to look back on everything that's happened over the past six weeks.

I've been working with the SunPy community on radiospectra and honestly, this experience has been very different from what I expected.

Sure, I've written code, opened pull requests and fixed bugs - but that's only part of the story.

The bigger lesson has been learning how an open-source project is built and how people from different parts of the world collaborate to make it better.

So instead of another weekly update, I thought I'd share a few things this journey has taught me so far.

Learning a Large Codebase Takes Time ⌚

When I opened the repository for the first time, it was... a lot.

There were spectrograms, WCS, NDCube, plotting code, metadata classes, different instrument readers, tests and somehow everything depended on everything else.

My first reaction was honestly,

"Where do I even begin?" 😅

At first, I felt like I wasn't making much progress because I was spending more time reading code than writing it.

I'd follow a single function into another file, then another and before I knew it, I had ten tabs open trying to understand how everything fit together.

Looking back, that was probably the most important part of the journey.

Once I understood why the code was written a certain way, making changes became much easier.

One thing I've learned is that understanding a project isn't time wasted - it's time invested.

Every Code Review Is a Learning Opportunity 💬

Before GSoC, I used to think code reviews were mainly about pointing out mistakes.

Now I see them very differently.

Some of my pull requests worked exactly as intended, but my mentors would still suggest changes - not because the code was wrong, but because there was a cleaner API, a simpler implementation, or a design that would be easier to maintain in the future.

Those conversations completely changed how I think while writing code.

Instead of asking myself,

"Does this work?"

I now find myself asking,

Is this easy to understand?
Does it fit naturally with the rest of the project?
Will this still make sense a year from now?
Can someone else build on top of this easily?

Those are questions I rarely thought about before GSoC.

Small Improvements Matter 😊

One thing I really appreciate about open source now is that every contribution doesn't have to be a huge feature.

Sometimes, making something a little easier for users is enough.

One of my recent pull requests focused on making spectrogram cropping more intuitive.

I worked on making spectrogram cropping easier for users.

Previously, users had to interact directly with the underlying NDCube API.

Now they can simply do this:




spec.crop_time(start, end)

instead of



spec.crop((start, None), (end, None))

Instead of interacting directly with the underlying NDCube API, users can now use simpler convenience methods.

It isn't a massive feature.

It probably won't make headlines.

But if it makes someone's life a little easier, I'd call that a success.

That's something GSoC has taught me - small improvements add up.

Communication Is Part of Engineering 🤝

This was probably the most unexpected lesson.

Writing code is only one part of contributing.

The other part is explaining your ideas, asking questions, discussing different approaches and responding to reviews.

At first, I was hesitant to ask questions because I thought I should already know the answers.

Thankfully, my mentors were incredibly patient and always encouraged discussion.

Over time, I realized that asking questions doesn't make you look inexperienced.

If anything, it shows that you're trying to understand the problem before jumping to a solution.

And more often than not, those conversations led to better ideas than I would have come up with on my own.

Progress Isn't Always Visible 🧠

There were weeks when I didn't have a shiny new merged pull request to show.

Earlier, that would've made me feel like I wasn't doing enough.

But during those same weeks, I was reading architecture, understanding how different components worked together, experimenting with ideas and having discussions with my mentors.

Those weeks were just as valuable.

Maybe even more.

One thing I've learned is that progress isn't always measured by commits or merged PRs.

Sometimes progress is simply understanding something that confused you yesterday.

Looking Back 📈

If someone had asked me six weeks ago what I'd learn during GSoC, I would've probably answered,

"Python."

Now my answer would be very different.

I've learned how to approach a large codebase.

I've learned how valuable thoughtful code reviews are.

I've become more comfortable asking questions and discussing design decisions.

Most importantly, I've learned that great software isn't built by one person writing perfect code.

It's built by people sharing ideas, reviewing each other's work and learning together.

What's Next? 🚀

Passing the midterm evaluation feels less like reaching the finish line and more like reaching the halfway point.

There's still a lot I want to learn and I'm excited about the work ahead.

Over the next few weeks, I'll be diving deeper into the architecture of radiospectra, working on larger improvements and hopefully contributing even more to the project.

I'm looking forward to sharing that journey in my next blog.

Thank You ❤️

Before wrapping up, I'd like to thank my mentors, Shane Maloney and Laura Hayes, for all their guidance, thoughtful feedback and encouragement throughout these six weeks.

Every review comment, every discussion and every suggestion has helped me grow, not just as an open-source contributor, but as a developer.

I'm excited to see what the second half of GSoC has in store.

See you in the next blog!