What I do

If you’ve read Why This, you already know I think of myself as an engineer.

I build software.

Simple.

It’s also the least interesting thing I’ve got to say.

Read on—or don’t.

Software was never the destination.

I didn’t choose it because I wanted to become a programmer, but because I discovered a medium where ideas don’t stay ideas for very long.

Finding software answered one question.

The next has proved considerably more difficult—and, I suspect, considerably more universal.

What is worth building?

Building Systems

That question gradually shifted my attention away from individual technologies and toward systems.

Not necessarily larger systems.

Systems that remain understandable as they evolve. Systems whose complexity is intentional rather than accidental. Systems where architecture isn’t an afterthought but a natural consequence of taking software seriously.

The more experience I gain, the more convinced I become that software engineering isn’t really about writing code.

It’s about making good decisions before, during, and long after the code exists.

Technology

Languages, databases, cloud platforms, messaging systems, AI—I’ve invested a great deal of time in all of them, and I don’t expect that to change. It demands an unusual amount of time and energy. I still believe it’s one of the best investments I can make.

Every technology changes the range of systems we’re capable of building.

That’s why understanding them matters.

Defining ourselves by them doesn’t.

I don’t expect my professional identity to revolve around a particular language, framework, or domain. Technologies shape how I think. They shouldn’t become the thing I think about.

Architecture

The longer I work in software, the less I think of architecture as a discipline sitting somewhere above engineering.

It feels more like what software engineering naturally grows into.

Once writing the code is no longer the difficult part, different questions take over.

Where should responsibilities live?

How should components communicate?

Which trade-offs are worth making?

How do we keep changing a system without gradually working against it?

In this profession, it is code that creates reality. That’s why I have no ambition to become someone who only designs systems. Building them is part of understanding them.

The Problems Worth Solving

You usually hear about distributed systems, platform engineering, cloud infrastructure, messaging, observability, or developer experience as separate disciplines.

I’ve gradually stopped looking at them that way.

To me, they all circle around the same question:

How do we keep building systems that remain understandable as complexity quietly keeps stacking the odds against us?

That’s the part I keep coming back to.

Not because complexity deserves admiration.

Because people using the software shouldn’t have to carry its weight.

Looking Ahead

I don’t see architecture as the destination of my career.

Broader engineering ownership feels like a much better description.

Taking an ambiguous problem—preferably an ambitious one—understanding it, shaping it into a system, building it, and remaining responsible for how it evolves afterwards.

That’s the direction I’m deliberately moving in.

Fortunately, it doesn’t feel like a lonely road.

This profession is full of remarkable engineers, and almost everything worth building has always been the result of people thinking together rather than alone.