What I’m trying to understand

Source: Dev.to

Background

I’m a software engineer at a mid‑level, and I started my career building web applications, mostly with Ruby on Rails. Over time I worked with other frameworks and frontend technologies while building SaaS products.

Frameworks helped me move fast: they provided 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.

Growing Awareness

At some point that feeling stopped being enough. The systems I built 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. Modern frameworks quietly take a lot off your plate—not in a bad way, but they also hide how software actually behaves over time. If you never look behind that curtain, you never really build intuition for it.

Where Software Is Going

I started thinking more about the future of software. It doesn’t feel like the future will be 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.

These concerns appear in practical discussions about distributed systems and in speculative conversations about autonomous systems or space exploration. As a Star Wars fan, I’m reminded of talks about traveling to the Moon or Mars and people living there one day. Yet we rarely stop to think about how software would actually behave in those environments: how systems communicate when messages are delayed, connections drop, and failure is part of normal operation.

Starting a Learning Log

I realized I didn’t want to abandon the tools I’ve been using or move away from web development and 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.