The Value of Scars: When Time Starts to Pay Off

I often find myself reflecting on the topic that has captivated me the most since I first encountered it in my professional journey as a software engineer. One quote that always comes to my mind is from Aristotle in Rhetoric, where he speaks about youth:

"They are confiding, because they have as yet not been often deceived; full of hope, for they are naturally as hot-blooded... and, besides, they have not yet experienced many failures. They are high-minded, for they have not yet been humbled by life, nor have they experienced the force of necessity."

As a less experienced developer, it's easy to be exposed to concepts like software design or software decisions and think you understand them. You might read through books and guides, watch tutorials, and feel confident in your knowledge. But here’s the truth: these concepts truly become valuable only when you’ve spent time facing real-world problems and dealing with the complexities of different systems—well-structured, poorly structured, messy, and everything in between.

Back when I was in college, I had a course where I was supposed to apply design patterns and MVP architecture. I was building a mobile app with Java, a language rich in object-oriented resources. There was no shortage of material or tutorials.

Yet, even though all the available knowledge, something crucial was missing—something that is central to making meaningful decisions in software design: the scars from real-life experiences.

I remember trying to apply various patterns without fully understanding why. Sure, I could justify some of my decisions, and looking back, some of the implementations now make sense. But back then, I didn’t understand the true value behind those decisions. I hadn’t experienced the kind of problems these patterns and rules were meant to solve.

Since that course, my interest in software design has only grown. I’ve made plenty of mistakes and tried various approaches, some of which were a bit out there. I can say with certainty that most of the time I was trying to solve imaginary problems.

That's what happens when you have all the theory, you have your surfboard ready, but you're still in a pool learning how to float.

One day, I realized that the right design decisions weren’t just about “this is the right way” or “this will give me X outcome.” They came from my own scars—lessons learned through experience. Suddenly, better design decisions just came naturally. There is no shortcut or trick, just the passage of time taking effect.

This is why, it’s not enough to just know the theory. To truly make valuable software design decisions, you need experience, time, and interest in understanding why certain choices work better than others. Sometimes, developers—especially those who are focused on just outcomes—don’t ask these questions. They just implement and move on. But it’s that deep curiosity and reflection over time that transforms a good developer into someone who can make impactful design decisions.

It’s completely normal to feel frustrated when you don’t understand why certain things are the way they are. I often experience that feeling myself, especially when I'm diving into something entirely new or when I realize I've misunderstood something. In those moments, it’s essential to be patient, stay focused on the present, and remember that time and consistency will eventually pay off.