Back

Wrapping Up GSoC: Key Learnings and Reflections

It's already the end of my Google Summer of Code journey and I wanted to take a moment to share some of the biggest learnings from these past months.

Shoutout: Learning Scala Efficiently

Even though I took Martin Odersky's Scala course at EPFL two years ago, the Rock the JVM courses turned out to be a lifesaver. They're ridiculously efficient: short, well-structured, and super easy to follow. Honestly, I don't think there's a faster way to get back up to speed with Scala. I was lucky that these courses were offered free of charge for all Scala Center GSoC contributors :))

Open Source & Community

Contributing to open source has been eye-opening. Senior developers took the time to review my code, explain things, and sometimes completely change how I think about programming. A few lessons from my mentors and experienced LLM4S contributors that genuinely changed my Scala code:

  • Leverage existing libraries: Experience is knowing when to rely on existing libraries and when to write custom code. Prefer battle-tested libs for parsing, JSON, IO, HTTP, etc., and spend your energy on domain logic.

  • Avoid raw strings: If something has a closed set of possibilities (commands, states, IDs, errors), model it as an ADT (sealed traits, enums, case classes). The compiler then forces you to handle every case, making your code safer and easier to maintain.

  • Methods should either do or compose: Instead of writing giant functions, break logic into small, single-purpose methods. Each one does one job, and then you "compose" them with for-comprehensions (usually they're more readable than compositions with map/flatMap). This style makes code shorter, more readable, and much easier to test.

  • Handle errors as data, not exceptions: In Scala you can represent errors with types like Option, Either, or Try. Instead of throwing exceptions (which are invisible in types), you return a value that explicitly says "this might fail." That makes failures predictable and easier to chain. Why Try is better than try/catch.
    In fact, this is just a special case of the next point: treating errors as data is one way of wrapping side effects so they don’t leak uncontrolled into your program.

  • Wrap side effects: Side effects are anything that touches the outside world: printing, hitting an API, reading a file. If you let them appear everywhere, the code becomes hard to test and reason about. The functional approach is to wrap side effects in a type (like IO, Future, or Task) so they don't just "happen": they're values you can pass around, compose, and control. Once wrapped, you can also push them to the edges of the system: keep the core logic pure functions, and only execute the actual side effects at the boundaries. More about this here.

Owning the roadmap

Contributing to a big, fast repo meant plans changed under my feet. I wasn't handed a to-do list; I had to decide what to build and defend those choices. For example, I proposed and built the assistant agent feature. It seemed like a missing piece, and while experimenting with it I hit the context window limits… which later pushed me to design a full context management system.

That cycle: discover pain → design → implement → explain → iterate, was the real growth.

Knowing the ecosystem is part of the job

This summer also connected me more deeply with the Scala ecosystem. I attended Scala Days in Lausanne, met some of the famous contributors in person (and my mentors!), and even saw my work presented on stage.
I learned that becoming a better developer isn't only about code, it's also about knowing the ecosystem. For example, my mentor often pointed me to Li Haoyi's libraries, which are known for being simple and practical. Understanding which libraries exist, who builds them, and what the community values is part of the "developer culture" that makes you more effective.

A principle I'll keep

One of my key takeaways is this principle that my mentor Rory often repeated: "Make it work first, then refine".
Start simple, then make it elegant, functional, and type-safe.

That's a wrap for my GSoC blogs. I learned more from the community than I can fit here — from code reviews to architecture debates — and it made me a better engineer.

A special thank you to my mentors, Kannupriya and Rory, who gave their time and energy freely throughout the summer. The fact that GSoC mentors volunteer, purely out of passion for teaching and open source, makes their support even more admirable. 💛