The Short Version
I have been building systems for over two decades, mostly behind the scenes. This is me finally sharing what I have learned - what worked, what did not, what broke spectacularly. Not claiming to have all the answers. Just sharing my journey in case it helps someone else avoid my mistakes.
The Longer Story
As a teenager, I wanted to be a cricketer. Programming was not even on my radar. That changed in my first year of college when I wrote my first lines of C code. Something clicked. From there it was C++, Java, JavaScript, HTML, CSS, C#, and the list kept growing. I have a Bachelor's and Master's degree in Computer Applications.
My career did not start in development. I began as a QA engineer, testing web applications through manual and automation testing. LoadRunner was my primary tool back then. I spent my days finding bugs and understanding how systems break. That experience shaped how I think about building software today.
The transition to development happened when the company I was working at started an in-house developer program. I was the only person who passed the qualifying test. After 45 days of intensive training in PHP and Ruby, I was promoted to Junior Software Engineer. That was the beginning of a different journey.
Through all of it, I have made plenty of mistakes. Some were small. Some were expensive. A few were the kind you remember for years. Each one taught me something that no tutorial or course ever could.
DECYON exists because I wish something like this existed when I was earlier in my journey. Not another tutorial site. Not another influencer promising quick wins. Just honest notes from someone who has been in the trenches, sharing what worked and what did not.
What I Work On
These days I work across several areas. AI systems are a big part of what I build, but not the demo kind. The kind that need to work reliably in production with real users and real constraints. I also build fintech applications, ETL tools, and enterprise-level systems.
Over the years I have worked on data engineering, data migration, code migration, backend architecture, and even a couple of blockchain projects. Each project taught me something different about how complex systems behave in the real world.
I am not a researcher or academic. I am an engineer who builds things. The insights I share come from that perspective, from actually shipping code and living with the consequences of my decisions.
Why I Write
Writing helps me think more clearly. When I have to explain something, I understand it better myself. And if what I write helps someone else avoid a mistake I made or see a problem differently, then that is a good use of my time.
I am not trying to build an audience or become an influencer. I just want to contribute something useful to the engineering community that has taught me so much over the years.
