Frontend wasn’t a box I needed to escape from

Dark coding workspace, photo by Jakub Żerdzicki on Unsplash
PRODUCT THINKINGStart with the person using it. Follow the problem wherever it goes.

Frontend has shaped the way I think about software, even as my work has moved much further across the stack.

That isn’t something I’m trying to leave behind. It gave me a product mindset, an eye for the experience at the end of the system and a habit of asking what the person using something will actually see when our technical decisions meet the real world.

More than just a UI

Early in my career I spent a lot of time building interfaces with React and React Native. That meant thinking about state, component design and performance, but it also meant being very close to the people using what we built.

You notice different things when you work at that end of a product. What happens when a request takes too long? What does someone see when it fails? Is the information understandable? Does the flow match the way they actually think about the task?

Those questions are still part of how I work. The difference now is that I can follow many of them further into the system.

Connecting the layers

As my career has evolved, I’ve enjoyed connecting that frontend experience with more of what happens behind the scenes. My work now takes me through APIs, SQL Server, AWS services, event-driven systems and Rust alongside the web and mobile technologies I started with.

That breadth changes the conversation. A slow screen might be a rendering problem, but it might also be the shape of a query, the way data is being fetched or a service doing more work than it needs to. A product requirement might sound simple in the UI but have consequences for data, permissions or how a process behaves when something fails halfway through.

I like being able to stay with those problems rather than treating the boundary between frontend and backend as somebody else’s concern.

User needs→Product thinking→Technical delivery→Better outcomes

A more complete engineer

Having started closer to the interface gives me useful instincts when I’m designing or reviewing the layers underneath it. I care about naming and contracts because I know how they surface to another developer. I care about failure states because I know somebody eventually has to experience them. I care about the shape of data because it affects what a product can sensibly do.

And the learning goes both ways. Working further into backend services, data and cloud has made me better at the frontend too. I make different decisions when I understand more of what has to happen to support them.

That is the part of full-stack engineering I enjoy most: not collecting technologies, but understanding how the pieces influence each other.

Looking ahead

I want to keep building on that breadth and taking on bigger problems. I’m particularly interested in the decisions that sit between product and engineering: shaping an approach, understanding the trade-offs, making the system understandable and helping a team get from an idea to something we’re confident putting in front of people.

Frontend wasn’t a detour from becoming a “real” engineer. It was the start of a perspective I still use every day. The difference now is that I can bring that perspective to much more of the system.

← Back to writing