I’m a software engineer, currently at a mid level. I started my career building web applications, mostly with Ruby on Rails, and later worked with other frameworks and frontend technologies while building SaaS products.
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, that stopped feeling enough.
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 usually 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, and 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 shows up in very practical discussions about distributed systems. Sometimes it appears in more speculative conversations about autonomous systems or 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 we rarely stop to think about how software would actually behave in those environments. How do systems communicate 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 didn’t want to abandon the tools I’d been using. I didn’t want to move away from web development or frameworks. I wanted to understand what they were abstracting away.
So this is the start of a series.
Not a tutorial series. Not a guide on how to become a systems engineer overnight.
This is a learning log. A place where I document how my thinking changes as I try to better understand software as something that runs over time, under constraints, and in the presence of failure and uncertainty.
Sometimes the posts will be short notes. Sometimes longer reflections. Sometimes corrections to ideas I previously believed were right.
I don’t know everything. But I want to understand a lot more than I do now, and I want to do that carefully, honestly, and as close to how software behaves in the real world as possible.
Top comments (0)