Developing software has always been one of the fastest‑growing fields, and today it’s both easier and more challenging than ever.

It’s easier because we can rely on powerful tools. I work mainly with C#, and its evolution has been incredible. But it’s also challenging because staying afloat in this constant flow of “new technologies” requires discipline — evaluating what truly helps and what’s just noise.

For me, a turning point was discovering Clean Code. I found many of my own ideas expressed more clearly than I could have articulated myself. And while I learn a lot from the experts out there, I sometimes feel slightly off track — not because of the technical part, but because of the common sense behind software design.

Simplification shouldn’t stop at fundamentals; it should permeate the entire project. Too often I see missing naming, missing terminology, and pragmatism used as an excuse for shortcuts. But why?

What I’ve learned is not to obsess over frameworks or rely too heavily on databases, but to write code that remains understandable over time. Simple terms. Clear naming. Explanatory variables. And tests — lots of tests. Learning what to test and how to test is an ongoing journey, but you can feel when you’re on the right path.

I’ve learned how to be more technical without behaving technically. I’ve learned to apply concepts, not just skills. And yes, sometimes my code could be shorter — but what’s the point if it becomes harder to read?

My goal is to deliver reliable, testable, and comprehensible code that stays readable and maintainable throughout the lifespan of a project. I believe Clean Architecture is one of the best ways to achieve that — cross‑language, cross‑platform, cross‑framework.

mahalo