Engineering in Four Dimensions: A Systems Thinkers Framework

One thing I love about engineering is that it changes how you see everything.

You stop looking at the world as a collection of random objects and start seeing relationships, coordinates, dependencies, constraints, and movement. You start asking different questions. Not just what is this? but where is it, what affects it, what is it relative to, and how does it change over time?

That way of thinking follows me everywhere. It shows up when Im building software. It shows up when Im designing systems. And interestingly, it also shows up when Im thinking about music.

The Fourth Coordinate

According to Einsteins general theory of relativity, to properly describe an event, you need four coordinates not just front-to-back, left-to-right, and up-to-down, but time as well. Time is not some detached container sitting outside reality. It is part of the structure of reality itself.

That idea stayed with me.

Because once you really absorb it, you begin to notice that a lot of meaningful work is not just about objects. It is about placement in space and behavior across time.

That is true in physics. It is true in software. And in its own way, it is true in sound.

Mixing Dimensions: Sound as a Four-Dimensional Problem

When I think about a mix, I dont just think in terms of this vocal is loud or this instrument needs EQ. I think in dimensions:

• Panning moves a sound left or right the horizontal plane.
• Frequency placement can make a sound feel higher or lower in the sonic field the vertical plane.
• Volume and depth cues make something feel closer or further away depth.
• Time is the dimension that turns a static sound into an experience.

That last part matters most.

Because sound without time is not really sound as we experience it. It is only data a frozen possibility. The moment time enters, it becomes movement, rhythm, contrast, delay, groove, anticipation, release. Time is what allows a listener to feel the structure instead of just technically observing it.

Software Is a Temporal System

A lot of people talk about software as if it is mostly code. But code is only the visible surface of a deeper reality. Underneath, software is coordination across dimensions: users, interfaces, data, infrastructure, logic and time. Especially time.

Consider how much of backend engineering is really time engineering:

• Latency is time.
• Retries are time.
• Queues are time.
• Caching is time.
• Rate limits are time.
• Timeouts are time.
• State transitions are time.

Even product decisions are often decisions about time: when the user sees something, how long a process takes, when trust is built, when friction appears, when feedback arrives, when complexity becomes unbearable.

A system can be technically correct and still feel broken because of how it behaves through time.

That fascinates me and its a tension I actively design against in projects like my Data Breach Scanner, where response latency and state feedback directly shape whether the tool feels trustworthy or broken.

The Relativity of Frames

One of the most beautiful implications of relativity is this: you never feel your own time drifting. Your own watch always feels normal to you. The shift only becomes meaningful in relation to another frame.

I think that applies to builders too.

Inside a system you are creating, everything can feel normal because you are moving with it. Your assumptions feel obvious. Your abstractions feel clean. Your workflow feels efficient. Your architecture makes sense because you have adapted to its internal rhythm.

But the user lives in another frame.

Your teammate lives in another frame.

Your future self definitely lives in another frame.

And that is where engineering maturity begins: when you stop designing only from your own frame of reference.

That is true for product. That is true for architecture. That is true for communication. That is true for leadership.

Multi-Perspective Architecture

As a founder-engineer, Ive become more aware that building is not just about making things work. It is about making them work relatively well from multiple points of view simultaneously:

• The database has a perspective.
• The API has a perspective.
• The frontend has a perspective.
• The user has a perspective.
• The business has a perspective.

Time exposes whether those perspectives are actually aligned or only temporarily quiet.

Mental Models as Compression

When I was younger, I thought mastery meant having the right answers. Now I think mastery is often about having the right mental models.

A good mental model compresses complexity without flattening truth. It lets you move between fields. It helps you see analogies that are not forced, but structural. It gives you a way to think when the surface details change.

This is one reason I care so much about systems thinking.

If you understand dimensions, relationships, and time, you start seeing why some things fail even when they look impressive. You start seeing why some products feel effortless while others feel heavy. You start seeing why certain teams move fast without chaos, while others produce constant motion without real progress.

You also start seeing yourself more clearly.

You realize that not every problem is solved by adding more. Sometimes the answer is repositioning. Sometimes it is removing noise. Sometimes it is changing the frame of reference. Sometimes it is recognizing that what looks wrong from one angle becomes obvious from another.

That is not just good engineering. That is good judgment.

The Deeper Work

Maybe that is what I am really trying to build whether in software, business, or thought not just outputs, but clearer ways of seeing.

Because once you can see a system properly, you can shape it properly.

And once you can shape it properly, you can serve people better.

That, to me, is the deeper work.

Not just writing code. Not just making things louder, faster, or more complex. But understanding where things are, how they move, what they relate to, and what time reveals about them.

Four dimensions.

Maybe more, depending on how honest you are.

Lets Build Together

I specialize in building secure, scalable software solutions. If youre looking for a software engineer with expertise in systems architecture and product engineering, take a look at my other projects or get in touch to discuss your needs.