The Cartography of Curiosity

I've had the "so what do you actually do?" conversation more times than I can count. Someone scrolls through my work (Kubernetes clusters, BPMN process engines, React apps, homelabs, encryption schemes, AI orchestration) and you can see them trying to fit it into a box. Backend guy? DevOps? Architect? They want a label, and I keep handing them a map instead.

For a while, that bothered me. I'd look at people who had this clean trajectory (junior Java dev, senior Java dev, Java architect, done) and wonder if I was doing it wrong. Spreading too thin. Chasing shiny things. The career equivalent of starting ten books and finishing none.

I don't think that anymore. And I want to explain why, because I think a lot of engineers feel the same quiet guilt about being interested in too many things.

Nobody Told Me the Straight Line Was Optional

The industry sells you this story early: pick a lane, go deep, become the person everyone calls when that one specific thing breaks. And look, that works. I've met brilliant people who've spent fifteen years in one corner of distributed systems and know it cold. I respect that.

But it was never going to be me. I'd get deep into something, feel like I had a grip on it, and then some adjacent problem would pull me sideways. I'd be optimizing a Maven build pipeline and start wondering how the whole CI/CD chain could be rearchitected. I'd be writing servlets and start thinking about the identity layer underneath them. I couldn't help it. The interesting stuff was always at the edges, where one domain bled into another.

The Stuff That Looked Like Detours Wasn't

Here's what I've learned after years of this: almost nothing I explored turned out to be wasted. It just took a while to see why.

I built a homelab. Proxmox, Docker Swarm, Gitea, Drone, the whole thing. Nobody asked me to. There was no ticket for it. I just wanted to understand what happens when you own every layer of the stack, from the bare metal up. Seemed like a hobby at the time. But years later, when I'm in a room making infrastructure decisions, I'm not guessing. I've run it. I've broken it at 2 AM and fixed it before morning. That's a different kind of knowledge than reading the docs.

I went deep on BPMN, CMMN, and DMN, process engineering standards that most developers have never even heard of. If you'd asked me at the time what I was going to do with that, I wouldn't have had a great answer. It just fascinated me, the idea that you could model complex workflows as first-class architectural artifacts instead of burying them in code. That "useless" detour is the entire foundation of HELM, the AI orchestration engine I built. Turns out the agent framework world was rediscovering problems that process engineers solved decades ago. I just happened to already know where the answers were.

Same thing with security. I didn't wake up one day and decide to become a security engineer. I was building Therasite, a healthcare application, and realized that if you're handling therapist-patient data, "add HTTPS and call it a day" doesn't cut it. I had to understand encryption at rest, HIPAA compliance, secure-by-default architecture. I went deep because the work demanded it. And now that knowledge shows up everywhere, in every system I design.

The thing is, none of these skills exist in isolation. An engineer who only knows engineering sees a technical problem. An engineer who also understands process design, security architecture, and infrastructure sees the actual problem, which is almost always messier and more connected than any single discipline can handle. The skills compound on each other in ways you can't predict upfront.

The Guilt Phase

I'll be honest, there was a period where I felt behind. I'd see people my age who were Staff Engineers at FAANG companies, deep specialists with clear titles and obvious trajectories. And here I was, building homelabs on weekends and reading about case management notation. It felt self-indulgent. Like I was playing while other people were building careers.

Angela Duckworth has a line I keep coming back to: "Before hard work comes play." The grit comes after you find the thing worth being gritty about. You can't white-knuckle your way through a career you picked at random.

That reframed things for me. The sampling period isn't the failure period. It's the part where you're gathering data on yourself. What energizes you. What drains you. What you keep coming back to even when nobody's paying you to. Some technologies stuck, some didn't. The ones that stuck (process engineering, infrastructure, secure architecture, AI orchestration) stuck because they matched how my brain works. Systems thinking. Layers. Connected wholes.

That's not being scattered. That's calibration.

Finding the Intersection

I'm not the best React developer. I'm not the best DevOps engineer. I'm not the best process modeler. But I might be the only person in the room who can connect all three. Who can look at a system and see the infrastructure, the workflow orchestration, the security model, and the user experience as one thing instead of four separate concerns.

That's where I ended up, not by planning it, but by following curiosity long enough for the pattern to emerge. You don't need to be world-class at any one thing. You need to be good enough at a few complementary things that almost nobody else combines. The intersection is where the value lives, and you only find it by doing enough different things that the overlap becomes obvious.

What I'd Tell a Younger Me

I'd tell a younger version of myself to stop feeling guilty about the wandering. The side projects, the rabbit holes, the "why does this work?" tangents at midnight. That's not a distraction from the real work. It is the real work. You're drawing a map of a territory you haven't fully seen yet, and one day you'll look at that map and realize you've been circling the same spot from different directions the whole time.

That spot is your thing. The place where your particular combination of skills and interests creates something nobody else would build quite the same way.

I couldn't have planned my way here. I had to wander here. And I think that's true for a lot of engineers who feel like their curiosity is a liability instead of their greatest asset.

It's not a liability. It never was. You just haven't finished the map yet.