ImaSystems.Engineer

I’m a software engineer, currently at a mid level. I started my career building web applications, mostly with Ruby on Rails. Over time I worked with other frameworks and frontend technologies, building SaaS products in environments that value speed, convenience, and developer productivity.

For a long time, this felt like the natural path. Frameworks helped me move fast. They gave me clear structures, familiar patterns, and a sense that I knew what was going on. Most of the complexity was handled for me, and I didn’t really question that.

At some point, though, I started feeling that something important was missing.

The systems I was building worked, but my understanding of them felt shallow in certain moments. I could explain the code, but not always what was happening once the system was running. I was comfortable thinking in terms of requests, responses, controllers, and services, but much less comfortable explaining things like retries, background work, partial failures, or why something behaved differently after a restart.

When production issues happened, the answers were often outside the parts of the system I was used to thinking about.

That’s when I started noticing how much modern frameworks quietly take off your plate. Not in a bad way. They’re designed to make development accessible and efficient. But they also hide a lot of how software actually behaves over time. And if you never look behind that curtain, you never really build intuition for it.

Around the same time, I started thinking more about where software is going.

It doesn’t feel like the future is purely request–response, instant feedback, perfect conditions. More and more systems operate in environments where latency exists, failures are normal, and things don’t always happen immediately or in the order you expect. Sometimes this is talked about in very practical terms, like distributed systems or autonomous systems. Sometimes it shows up in more speculative discussions, like space exploration.

I’m a Star Wars fan, so maybe that plays a role here. We talk a lot about traveling to the Moon or Mars, about people living there one day. But rarely do we stop and seriously think about how systems would communicate in those environments. How do you design software when messages are delayed, connections drop, and failure is part of normal operation?

Thinking about that made me feel small, but in a good way.

I realized I was a software engineer building SaaS products with Rails, React, Vue, and similar tools, while there was an entire layer of reality I hadn’t really explored yet. Not because I was careless, but because the tools I used were intentionally designed to keep me focused elsewhere.

I didn’t want to move away from those tools. I wanted to understand what they were abstracting away.

I wanted to grow into someone who can think about software as something that runs over time, under constraints, and in the presence of failure and uncertainty. Someone who understands abstractions instead of just relying on them. Someone who designs systems with execution in mind, not just structure.

That’s what this site is about.

ImaSystems.Engineer is my learning log. Sometimes it’s short notes. Sometimes longer essays. Sometimes design documents. Sometimes corrections to ideas I previously believed were right. It’s not a place where I claim expertise. It’s a place where I document how my thinking changes as I learn.

I don’t know everything. But I want to understand a lot more than I do now, and I want to do that honestly, carefully, and in a way that stays close to how software actually behaves once it’s running in the real world.