It’s time to meet one of the people working at the very core of natESM’s technical engine: Research Software Engineer (RSE) Wilton Jaciel Loch. Originally from Brazil, Wilton joined natESM in October 2022 after moving to Europe in search of meaningful, collaborative work in high-performance computing. In this deep dive, he shares his journey, his approach to sprint collaboration, and how his passion for dance influences the way he navigates code and complexity. For Wilton, sprint proposals aren’t just applications – they’re invitations to move forward together.

Interview: Iris Ehlert, July 2025

natESM: Wilton, can you tell us a bit about your journey? How did you end up working with Earth system models in Germany?

Wilton: I started out studying computer science in Brazil, first at a technical high school and then at university. I was always curious about how things work – machines, networks, software. Eventually, I got into research, but honestly: being a researcher in Brazil isn’t easy. It’s underpaid and underappreciated.
I wanted to keep working on interesting problems, but I also needed stability. That made me look for opportunities in Europe, where research positions offered more support and long-term prospects.One of the first stops on that journey was a PhD position in Vienna, but it turned out to be a mismatch – the work was closer to physics than computer science, and I wasn’t happy.

Eventually, I realized: I don’t want to write papers, I want to solve problems.
When I found the RSE position at DKRZ, it felt like exactly what I had been looking for.

What do you enjoy most abour your role as an RSE in natESM?

Being able to contribute to something meaningful. There’s the bigger picture – helping climate science move forward – but also the day-to-day satisfaction of improving software, fixing issues, and enabling models to do more with less. That combination is what keeps me going.

How would you describe your working style?

I have an aversion to complexity [laughs]. Over time, I’ve learned that keeping things simple is the best way to make progress. I like to work in very small, verifiable steps – “baby steps.” If something feels overwhelming or hard to trace, I try to break it down into the smallest useful unit and focus on that. It’s more sustainable and less stressful – and in most cases, it also leads to better results.

How does that play out dring sprints?

In projects where I already know the code – like CLEO – I can often outline 15–20 small, concrete tasks that lead toward the sprint goal. We had that in one of the CLEO sprints, and it worked really well.
In less familiar codebases, I start even smaller – just verifying whether something initializes correctly, whether communication between components works, and so on. You can’t solve big problems without understanding the basics.

Do you think your Brazilian background influences the way you work?

I think so, yes. There’s this concept in Brazil called gambiarra. It’s hard to translate, but basically it’s about solving problems with whatever you have on hand. It’s a cultural attitude – making things work, even if it’s not perfect or elegant. That mindset helps me a lot when I work with messy code or unclear requirements. So, gambiarra taught me to keep moving, even when the tools aren’t perfect. Sometimes you just need to get creative and move things forward, step by step.

What helps you recharge or feel inspired outside of work?

Dancing! That’s definitely my main thing right now. I got into it last year and now have been doing it quite often. I never expected it to become such a big part of my life, but now I really love it. It helps me disconnect and brings a whole different kind of joy. I mainly dance Forró, a Brazilian partner dance.

It also inspires how I think about work. In a way, each sprint is like a new rhythm. You tune into your partner – the scientist – listen to where they want to go, and then you start moving together. We dance together in the sprint – andsometimes I follow, sometimes I lead. But the important thing is to find a shared flow.

» If you’re too rigid, the rhythm breaks. But if you’re present and adaptable, you can create something great together. «

That’s a beautiful metaphor. Would you say sprint work is like dancing with complexity?

Yes! With complexity and with people. Collaboration is always a bit unpredictable. You need timing, patience, and openness. If you’re too rigid, the rhythm breaks. But if you’re present and adaptable, you can create something great together.
You’ve supported several sprints now. What makes a sprint successful in your eyes?
For me, it’s about productive collaboration. When there’s trust, good communication, and a shared understanding of what we’re trying to do, the technical work becomes easier.
I’ve had great experiences when scientists were open to suggestions, and we could shape the sprint together. One of the best examples was the CLEO sprint where we made consistent progress through small steps. It wasn’t just about reaching the goal – it was about the way we got there.

» The sprint check is like a first dance: we figure out if the rhythm fits. «

You’ve also helped develop how sprint proposals are written. What’s your take on the sprint-check process?

The sprint check is meant as a service for scientists – not as a gatekeeping moment. Our job as RSEs is to sit down with them and give an honest, technical first impression: Does the code look maintainable? What would be a good starting point? Are the goals realistic? We also give feedback on whether the software is at a point where a sprint makes sense.
And then, we also help shape the application – the scope, the timeline, the plan. We’re not there to decide whether the project gets funded, but we do help frame the process. The sprint check is like a first dance: we figure out if the rhythm fits, and how we might move forward together.


We recently discussed the idea of shorter “profiling” sprints – can you explain that?

Sometimes people come with vague ideas, but they don’t yet know what the technical bottlenecks are. In those cases, a short profiling sprint can be helpful. It gives us a chance to study the code, run tests, and figure out where the effort should go.
It’s like mapping the terrain before you build a house. And it helps avoid writing an overambitious proposal based on guesses.

What would you like others in the community to better understand about your role as an RSE?

What I wish more people understood is that we’re not here to solve everything in advance. We’re an integral part of the process – technical collaborators who help shape the sprints.
And we’re happy to help – especially when people come with curiosity and a willingness to work together. Sprint proposals are not just applications; they’re invitations to collaborate for the long haul. And that’s something I really enjoy.

Wilton sketching systems during natESM team day in July 2025 @DKRZ