I TEND TO END UP WHERE THINGS GET COMPLICATED.

THE ENVIRONMENTS CHANGED. THE PROBLEM DIDN'T.

I've worked on backend platforms, APIs, distributed processing systems and real-time data pipelines.

I've also worked much closer to the physical world: industrial edge systems running on constrained hardware, communicating through protocols like MQTT, Modbus, TCP, UDP and ADS, deployed at customer sites where connectivity, resources and failure modes were very different from a typical cloud environment.

Those systems look very different on paper.

But they tend to create the same underlying problem:

There is more complexity than can be understood by looking at one piece of the system at a time.

THAT'S WHAT I LIKE WORKING ON.

I enjoy figuring out how the pieces actually fit together.

Where the boundaries should be. Which constraints are real. What needs to happen in real time. What happens when something fails. Which abstractions are useful and which ones are just adding another layer of complexity.

That usually means going deeper than the initial problem suggests.

A performance problem might actually be a data-model problem. A scaling problem might actually be a workload-management problem. A messy codebase might actually be suffering from unclear boundaries.

I like finding the problem underneath the problem.

ARCHITECTURE WITHOUT LEAVING ENGINEERING BEHIND.

Over the years, my role moved from implementing individual services to taking responsibility for how larger systems fit together.

I've designed systems from scratch, evolved existing architectures, investigated difficult performance problems, changed database models, worked with constrained hardware and integrated systems that don't behave like ordinary software.

I've also led small engineering teams and worked closely with other engineers to turn ambiguous problems into something concrete enough to build.

I still write code.

For me, architecture isn't about moving away from engineering.

It's about making better engineering decisions before — and while — the code is being written.

A COUPLE OF SYSTEMS THAT REPRESENT THE KIND OF WORK I ENJOY.

THE ENGINEERING NOTEBOOK.

I started the Engineering Notebook to document the reasoning behind this kind of work.

Not tutorials. Not technology lists.

Technical stories about real systems: what made them difficult, which constraints mattered, what decisions were made, what went wrong, and why the architecture ended up the way it did.