“The hardest problems are usually the ones nobody has documented, nobody has solved, and nobody can tell you how to fix.”
Interview with Tomasz Godzik, Lead Scala OSS Developer at VirtusLab
Most developers build software for a specific customer. Tomasz Godzik works in a very different environment. As one of the engineers behind Scala open-source projects such as Metals and the Scala 3 compiler, his users can be anyone - from developers inside large organizations to contributors on the other side of the world. We talked about open source, development tooling, AI, and the kind of mindset required to solve problems that often have no documented solution.
Your role is quite different from a typical software engineering position. What makes it unique?
One of the biggest differences is that I don't really have a single customer. Because most of my work is open source, the people using our tools can be anyone. That also means getting feedback is much harder. Sometimes somebody appears, reports an issue, and you have one opportunity to understand what's happening before they disappear again.
One of my main projects is Metals, a Scala language server. We provide information about the language that editors use to offer features like navigation, testing support, diagnostics, and other developer tooling capabilities. Besides that, I also lead the Scala 3 compiler team at Virtuslab, contribute to the Scala 3 ecosystem and various smaller open-source projects whenever something important needs fixing.
In practice, if there's a problem in the Scala open-source world and nobody else is available to solve it, there's a good chance we'll end up looking at it.
Did you consciously choose a career in Developer Experience and tooling?
Not really. It happened quite naturally. Years ago, I worked on different Scala-related projects and gradually found myself moving closer to tooling and developer-focused problems. Back then, we didn't really call it Developer Experience. It was more about improving the software development lifecycle and solving difficult engineering problems.
What kept me interested was the type of challenges involved. Very often you're dealing with issues that simply aren't documented anywhere. You search online and find nothing useful. Sometimes you find a Stack Overflow question you asked yourself a few years earlier 🙂
And there's still no answer. That actually happened to me.
What happens when you encounter a problem nobody seems to have solved before?
Today it's easier than it used to be because we have access to LLMs. They don't necessarily give you the answer, but they're often very useful as a debugging companion. Even when the suggestions aren't correct, they can help you explore different directions and structure the investigation.
I don't think they "know" the answer in the traditional sense. What they're often good at is reproducing the way people approach debugging. They've seen countless discussions, GitHub issues, and technical conversations, so they can suggest possible paths forward.
Of course, there are still situations where they get stuck. That's when human experience becomes important. Sometimes you need to approach the problem from a completely different angle. The AI wouldn't necessarily think of that, but an engineer who understands what's happening can redirect the investigation and test new ideas.
The biggest advantage is speed. What might have taken a day of manual investigation can sometimes be narrowed down in twenty minutes. They're not perfect tools, but if you understand what they're doing, they're incredibly valuable.
A lot of what you describe seems to involve figuring things out without a clear guide. What does that require from an engineer?
For me, it means being willing to take ownership of problems even when they're outside your comfort zone.
Tooling is an endless stream of unfamiliar topics. One day you're working on a compiler-related issue, the next you're investigating build systems, IDE integrations, AI workflows, or some completely new challenge you've never seen before.
You can't rely on already knowing everything. The important thing is being able to learn quickly, use the tools available to you, and gradually build enough understanding to propose a solution.
That's where modern tools help a lot. Even when a topic is unfamiliar, you can investigate it much faster than before. But you still need curiosity and initiative. Nobody is going to hand you a step-by-step guide.
What's the biggest challenge in your day-to-day work?
Users reporting problems without giving enough information. That sounds simple, but it's probably one of the hardest parts of maintaining open-source tools.
Someone opens an issue and says, "This doesn't work." Maybe they provide a version number and a short description. The problem is that our tools often operate directly on user code, and without seeing that code it can be extremely difficult to understand what actually happened.
Then the challenge becomes reproducing the issue yourself. You try to imagine what kind of project could trigger the bug, what conditions might cause it, and whether you can create a smaller example that behaves the same way.
Sometimes users can't provide more information because they're working inside large companies. Sometimes they don't know what information is relevant. Sometimes they simply disappear. When someone gives us a minimal reproducible example, fixing the problem is often straightforward. Getting enough information to reach that point is usually the real challenge.
Does working on developer tooling create a different kind of complexity than traditional product development?
Definitely. When you're building a regular application, you usually have a defined set of features and expected user behaviors. We don't have that luxury.
Our users are developers, and developers are very creative. They continuously invent new ways of using tools, new project structures, new integrations, and occasionally new ways to break things. The number of possible edge cases is effectively unlimited because user code can become arbitrarily complex. Every project is different. Every environment is different.
As tool creators, we can't really restrict the space where bugs might appear. We have to assume that people will do things we never expected. And very often they do.
How do you see AI changing software development over the next few years?
AI is already making developers significantly more productive, but I also think we're starting to see some of the risks. One problem is that many people use AI-generated code without fully understanding it. The result can be software that appears to work initially but becomes difficult to maintain, difficult to debug, and full of hidden problems. I think we'll need stronger processes and stronger guarantees around software quality.
Personally, I'm a strong believer in languages and tooling that provide more confidence and correctness. Naturally, Scala is one example, but the broader principle matters more than any specific language.
The more checks, validations, and guarantees you have before code reaches production, the better. And regardless of the technology, developers need to understand what AI is producing instead of treating it as a black box.
What motivates you after all these years?
Obviously, everybody works for money. But if money were the only thing that mattered, there are easier ways to optimize for that.
What I genuinely enjoy is seeing that my work helps people. We receive feedback from developers who are happy because a bug was fixed, a feature was added, or something that used to be frustrating now works properly.
That's rewarding because these tools aren't used by a handful of people. Sometimes they're used by thousands.
I also enjoy the sense of responsibility that comes with maintaining important projects. Knowing that people rely on something you've built creates a strong motivation to keep improving it. And honestly, hearing someone say, "This works great, thank you," never really gets old.
What kind of person thrives in this environment?
Communication skills are much more important than most people expect.
People often imagine developer tooling as highly technical work done in isolation. In reality, you're constantly talking to users, maintainers, contributors, and other engineers. You need to be comfortable asking questions, gathering information, and understanding problems that aren't always clearly described.
Curiosity is equally important. The best people in this space aren't necessarily the ones who already know everything. They're the ones who aren't afraid of unfamiliar problems and are willing to investigate until they understand what's happening.
You also need a certain level of independence. There won't always be a documented solution, a tutorial, or somebody who can tell you exactly what to do next. If that uncertainty excites you rather than scares you, you'll probably enjoy tooling.
