Learning to Learn: How Platform Work Changed the Way I Think About Engineering

Some roles teach you new tools. Others fundamentally change how you think.

My time working on the Migrations team has been firmly in the second category.

The team’s mandate was straightforward on paper: migrate legacy applications running on virtual machines to Kubernetes and cloud-based infrastructure. In practice, it was anything but simple. Each migration was its own ecosystem—different languages, architectures, assumptions, and historical baggage. And when I joined, I had never used Kubernetes before.

I had worked with Docker, but Kubernetes was a different world entirely. Early on, I realized that this role wasn’t about becoming a Kubernetes expert as quickly as possible. It was about developing the ability to understand systems deeply enough to move them safely, regardless of how unfamiliar they were.

Engineering Beyond Syntax

One of the most formative aspects of the role was working with “pretty much any programming language” the applications were written in. Java, PHP, Ruby on Rails, Python—sometimes all in close succession. At first, this felt intimidating. But over time, something clicked.

I began to see clearly that software engineering is not about syntax. Syntax is the surface. The real work lies underneath: understanding data flow, runtime behavior, failure modes, configuration, and how systems interact with their environment. Once you understand those fundamentals, languages become interchangeable tools rather than barriers.

This realization has stayed with me. Today, when I encounter a new language or framework, my first instinct is no longer “I don’t know this,” but “What problem is this trying to solve, and how does it do that?”

Adapting Tools to Reality

Another major part of the role involved modifying internal tooling to support different migration scenarios. These tools weren’t static—they had to evolve alongside the projects we were migrating. That meant diving into codebases written in languages I had never worked with before, especially Ruby on Rails and Python.

There was no luxury of long onboarding periods or perfect documentation. I had to read code, form mental models quickly, and make changes that were safe, maintainable, and aligned with broader platform goals. This kind of work sharpened my judgment as an engineer. It forced me to balance speed with caution and to think in terms of systems, not just features.

Becoming a Platform Engineer (Without the Title)

A large portion of the work fell squarely into platform engineering: containerization, aligning applications with twelve-factor principles, CI/CD pipelines, observability concerns, security boundaries, and operational safety in Kubernetes. It stretched me in ways few roles had before.

There were moments of genuine discomfort—when nothing worked, when production risks felt heavy, when the learning curve seemed endless. But growth tends to live right there, in that uncomfortable zone. Over time, I built confidence not because things became easy, but because I learned how to navigate complexity.

A Defining Chapter

Looking back, this experience stands out as one of the biggest career inflection points for me since my work on PHPSandbox. It reshaped how I approach unfamiliar problems, how I learn, and how I define myself as an engineer.

I didn’t just learn Kubernetes. I learned how to learn under pressure, how to reason about systems I didn’t build, and how to adapt quickly without losing rigor.

It stretched me. A lot.

But yeah—I survived. And more importantly, I grew.

I’m genuinely happy to be here.