Most software doesn’t fail because of bad code. It fails because the problem wasn’t understood in the first place.
People want to automate the things they can’t do themselves. That’s why they turn to software. But here’s the thing: if you don’t know how to do something manually, how do you expect to automate it?
Software is about translation. You take what you do—or what you want to do—and break it into clear, actionable steps. Steps a computer can follow.
That sounds simple. But describing what you do is deceptively difficult.
We often act intuitively. We don’t stop to think about why or how. But software demands precision. It requires you to name each step, each rule, and each exception. And the moment you try, you realise: maybe you didn’t understand your own process as well as you thought.
The difficulty grows when the goal is something entirely new. How do you describe a process you’ve never done before? How do you imagine something unfamiliar, and then translate it into a rigid system?
That’s the real work of building software. It’s not about writing code—it’s about defining the goal, imagining the steps, and staying grounded in both the big picture and the tiny details.
It’s about moving back and forth. From vision to description. From abstract ideas to concrete actions. And doing this without getting lost.
Because in the end, bad software isn’t the result of bad programming. It’s the result of losing sight of what you were trying to achieve in the first place.