On February 27, 2026, I had a meeting with my team lead, Pascal. The invite simply said “Discussion Marine <> Pascal”. I wondered if I had done something wrong. That is why my first reaction to his question was relief. He asked, “Do you want to work with the Perl legacy code full time?” Then came the surprise. Honestly, that was not the first thing that would come to mind when I was thinking about my full-time start. I had just graduated from a dual apprenticeship/university program. I thought I would spend the following years programming in our recent tech stack, namely Vue.js/TypeScript for the frontend and Elixir in the backend, having to touch our legacy Perl code only occasionally.

Winning the Learning Lottery

However, it didn’t take me until the end of the meeting to be sure of one thing: I’m in. I started to feel like a lottery winner: what an opportunity not to define myself through the tools (programming languages) we use and instead to dive deeper into the core software engineering practices: Managing complexity by defining clear interfaces and boundaries. Working in small batches for faster feedback on the effect of change. TDD, Refactoring, DDD and Pair Programming. Focusing on the first principles of software engineering.

That is how I willingly joined the Perl Archive & Technical Hub (PATH) Team. We are a group of four. Marcel and I are the core members. André and Johannes are our enabling team.

Our Mission: Reducing Cognitive Load

Our mission is to reduce the cognitive load on other developing teams and alleviate onboarding pain by isolating our legacy Perl code, transforming it into a low-maintenance platform with a clear interface that can be used in self-service. This is achieved through: reducing context switching between Elixir, Perl and Vue.js/Typescript because one does not have to learn Perl, and clarifying usage thanks to the clear interface of the platform. As the book “Team Topologies” states, minimizing cognitive load for others is one of the most useful heuristics for good software development.

The PATH Team Logo

We will achieve that by

  1. Becoming the Bottleneck: We are the only group that can change the Perl code. Any necessary change must come through us. We force collaboration by design to make use cases visible. We label all related PRs and track these interactions. We even enforced this at the repo level. No one can merge a Perl pull request without PATH team approval. We made ourselves the bottleneck on purpose to clarify functional dependencies.

  2. Securing Full-Time Allocation: The core PATH team is assigned to this full time. There is no clear end date. If it takes over a year, so be it. This gives us the resources to think long-term. We do not have to rush to a fast, fragile solution.

What Comes Next

As a byproduct of owning the Perl code, we also handle the related reactive work. This includes managing errors and bugs from our logs and our Perl (Minion) queue.

Our first target is reversing the API contract so Elixir calls Perl instead of the other way around. My senior teammates are leading the architectural design, and we are tackling the implementation together. We are figuring out how to use OpenAPI specs, contract linting, and JWTs to secure these new boundaries. Next time, I will share a scout report from our pairing sessions. I will cover the friction we hit, the questions I wondered about, and what is starting to click for me as we build this out.