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 work was mostly Python. I was drawn to systems around 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.
My first projects at LinkedIn 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.
I've said this for years:
UX is more important than UI.
A clear, functional product will beat a beautiful yet confusing one.
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 asking whether the feature 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.
A frontend or backend specialist can work this way. Full-stack range helps because it removes blind spots, but breadth isn't the point. Ownership is.
Agility in the age of AI
AI is shortening the distance between an idea and working code. It can draft an MVP, write queries, design databases, explain an unfamiliar codebase, or help test an approach in minutes.
That makes agility more valuable. For me, agility is being able to enter an unfamiliar problem, understand enough to move, and change direction when reality disagrees with the plan. The ceremonies and tickets are mostly beside the point.
AI makes code cheaper when it's used well. It doesn't decide what should exist, recognize every subtle failure, or own what happens after a feature ships. The more plausible code we can produce, the more judgment and technical fundamentals matter.
And the strongest engineers will be the ones who can move quickly and still explain what the code actually does.
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. I try to understand enough of the whole problem that no single layer becomes the limit.