What Do I Actually Do?

I've always liked the title of full-stack software engineer.

There is a certain seductive allure to it: it implies, "I can do anything."

At first, I thought it simply meant that I could handle both frontend and backend. As I gained more experience, however, I realized that it was a much heavier title to bear than I had originally thought. The stack, after all, does not have only two dimensions. Therein lies the issue with the title: "full-stack" means different things in different contexts.

These days, I think of the stack as a collection of levers.

I don't claim to be an expert in every one of them, although I am more proficient in some than others. What I do have is the confidence to get into the weeds with any of them when the problem demands it.

Over time, though, I've become less attached to the title itself. "Full-stack engineer" describes some of the tools I can reach for, but it doesn't describe what I fundamentally do. I solve problems. Sometimes that means designing an interface; sometimes it means tracing a database bottleneck, building an API, working with a model, or fixing a deployment pipeline. The stack changes with the problem.

I'm comfortable using any combination of these levers, and I try not to let habit decide which combination I reach for. It's tempting to let my enjoyment of one part of the stack turn into a default choice. That leads to a familiar pattern: picking the tools we know best and trying to make them fit every situation.

Specialization itself isn't the problem. The danger is allowing familiarity to make the decision for me, reaching for the same tool before I've properly understood the problem. I may eventually specialize, and my official title will almost certainly change. Neither feels particularly important to me. What I want to preserve is the willingness to approach a problem without deciding in advance which part of the stack should solve it. The tools are levers; the work is understanding which ones to pull.