I started my career closer to the backend. Today, I work across the stack. Somewhere along that path, the label became less important than how much of the product I was willing to own.
Moving closer to the product
My early interests were all things Python. I was drawn to real-time data, streaming, and processing. I spent a lot of time thinking about what happened behind the interface: how data moved, where latency came from, and what could fail along the way.
Joining LinkedIn, my first projects leaned backend too, at least for a short while. I eventually moved toward frontend work because it gave me more room to shape the product directly. The browser offered a tighter feedback loop. I could build something, put it in front of people, and quickly see where it made sense or fell apart.
It also taught me that the interface isn't just the last layer of a system. For most people, the interface is the system. A technically correct product can still fail when its state is unclear, its errors arrive too late, or its language assumes too much.
Over time, experimentation and measurement work pulled me back across the boundary. A single workflow could involve component state, data contracts, lifecycle events, caching, telemetry, and data integrity. The work didn't fit neatly into frontend or backend, and trying to keep it inside one layer usually made the product worse.
Ownership over labels
That's what product engineering means to me. It's a way of working that can happen anywhere in the stack.
I want to understand the customer and the business, turn a fuzzy problem into something buildable, and make reasonable tradeoffs before every detail is known. Sometimes that means writing UI code. Sometimes it means tracing an event through a pipeline or A/B testing a feature to see if it should exist at all.
This kind of ownership still takes a team, and I lean on people who are deeper in areas where I'm not. I stay attached to the outcome after the code is merged. Frontend is still my specialty, but it doesn't have to be the boundary of what I own. Full-stack range helps, but breadth isn't the point. Ownership is.
Stay agile
For me, agility is being able to enter an unfamiliar problem, understand enough to move, and change direction when reality disagrees with the plan.
I rarely have every answer at the start. I get oriented, make a safe first move, test the assumptions behind it, and adjust when I learn more. AI can shorten that loop by making prototypes and unfamiliar code cheaper to explore, but the important part is still knowing when to change direction.
Fundamentals travel
Frameworks change. Fundamentals travel.
On the web, that means looking past a component API to semantics, accessibility, layout, browser behavior, networks, and performance. On the backend, it means understanding data models, consistency, caching, events, authorization, and recovery.
A slow interface might begin with a database query. Confusing state might come from an unclear API contract. A broken experiment might be caused by event ordering rather than anything visible in the UI. The seams are often where the real product problems hide.
My path hasn't really been backend, then frontend, then full stack. It has been a gradual widening of ownership so no single layer becomes the limit.