About me

Let’s rewind a bit

Picture a dimly lit bedroom somewhere in India. The kind of room where the ceiling fan makes just enough noise to be mildly concerning, and the internet connection is hanging on by sheer willpower. There’s a kid sitting too close to a glowing monitor, squinting at what can only be described as a crime against web design.

I’m talking about a movie-download website. My movie-download website.

And when I say bad, I don’t mean “could use some polish.” I mean it looked like a fever dream coded during a power outage. The layout had no business existing. Fonts were chosen like they were pulled from a hat. Buttons were… technically there. Colors clashed with a level of confidence that, in hindsight, I almost admire. If design principles were laws, this site was a repeat offender.

But here’s the part that mattered: it worked.

You could click something, and something would happen. Files appeared. Pages changed. The system responded. To teenage me, that wasn’t just functionality. It was magic. I didn’t understand half of what I was doing, but I knew I had created something that people could interact with. That realization hits differently when you’re starting out. It’s not about best practices or scalability or clean architecture. It’s just: I made this. And it does a thing.

The site is long gone now, mercifully. No screenshots, no surviving code, no digital evidence that could be used against me. But the spark it lit? That stuck around.

And it didn’t just stick around. It escalated.

How it actually started spiraling (in the best way)

Once you get that first taste of “this works,” there’s no going back. I started pulling at threads, and suddenly I was deep into documentation rabbit holes at hours I probably shouldn’t admit publicly.

C came first. Which, in retrospect, is a bit like learning to swim by jumping into the deep end with weights strapped to your ankles. It was confusing, frustrating, and occasionally made me question my life choices. But it taught me how things actually work under the hood. Memory, pointers, the kind of details that either break your spirit or build it.

Python showed up next, like a friend who says, “hey, it doesn’t have to be that hard.” Things started clicking faster. I could build more, break more, fix more. Then C++ walked in uninvited, added complexity back into my life, and somehow I went along with it anyway.

Looking back, that phase was a cycle:

build something → break it → fix it → accidentally break something else → repeat

And honestly, that loop is where most of the learning happened. Not in perfectly following tutorials, but in going off-script and dealing with the consequences.

Somewhere along the way, I realized something important: I didn’t just enjoy writing code.

I loved building things people could use.

Not just logic. Not just output in a terminal. I mean interfaces. Visuals. Interactions. That moment when a UI feels right. When a button sits exactly where it should, when a transition is smooth enough to feel invisible, when everything just clicks. That’s the part that got me hooked.

Enter: modern frontend chaos (and clarity)

Then came React.

And I know people love to debate frameworks like it’s a sport, but for me, React genuinely changed how I thought about building interfaces. Suddenly, UI wasn’t this scattered mess of HTML, CSS, and JavaScript glued together with hope. It became composable. Structured. Predictable in a way that felt powerful.

Components made sense to my brain.

Then Next.js showed up and quietly removed a bunch of problems I didn’t even realize I was solving poorly. Routing, rendering strategies, performance. Things just started falling into place. It felt like upgrading from “somehow it works” to “this actually makes sense.”

Add TailwindCSS into the mix, and styling stopped being a battle. No more naming things like container-wrapper-final-v2. You just write what you need, right where you need it. It’s fast, it’s consistent, and it fits the way I like to think.

For data, Firebase became the go-to. Quick to set up, easy to integrate, and perfect for the kind of projects I tend to build at unreasonable hours of the night.

That stack. Next.js, React, TailwindCSS, Firebase. That’s my 2 AM stack. And if you know developers, you know that’s the most honest stack there is. It’s what you reach for when nobody’s watching, when you just want to build something without friction.

I’ve worked with MySQL, Supabase, Django, and a handful of other tools along the way. Each of them taught me something useful. But there’s always that one combination that just clicks. The one where your brain stops fighting the tools and starts focusing on the product.

The shift no one really explains

The technical journey is one thing.

The career journey is… different.

There’s a moment, and it kind of sneaks up on you, where you stop being the person nervously submitting pull requests and start being the one reviewing them. You go from “I hope this works” to “let’s think about how this scales.” From “me vs. the bug” to “us vs. the problem.”

And that shift changes how you think.

Leading an engineering team isn’t just “coding, but more.” It’s a completely different skill set. You’re thinking about architecture, yes, but also about people. Communication. Trade-offs. Deadlines that exist in the real world, not just in your IDE.

You start asking different questions:

• Is this maintainable?
• Can someone else understand this six months from now?
• Are we solving the right problem, or just the most obvious one?

There’s also a quiet satisfaction in it. Not the loud, immediate “it works!” feeling you get from fixing a bug, but something more subtle. Watching a team ship something solid. Seeing ideas evolve through collaboration. Knowing you helped create the environment where that could happen.

It’s less about writing every line of code, and more about making sure the right lines get written.

Outside the terminal (but not really)

When I’m not in a codebase, I’m usually still orbiting one.

I write. A lot.

Blog posts, DEV articles, random notes. Mostly about things I’ve learned the hard way. Because if I had to struggle through something for hours, there’s a decent chance someone else is going through the same thing right now. And if I can make that process even slightly less painful, that feels worth it.

It’s also a way of thinking more clearly. Explaining something forces you to actually understand it, not just “it works, don’t touch it.”

I also read, widely and without much loyalty to a single genre. Sci-fi is the obvious favorite, the kind that leaves you staring at the ceiling questioning reality, but I drift into anything that feels interesting. Philosophy, psychology, the occasional non-fiction deep dive, even the kind of books you pick up randomly and end up finishing in one sitting for no good reason.

At some point, I started tracking that habit too. Partly out of curiosity, partly because patterns are fun to look at. If you’re the type who likes that sort of thing, you can actually peek into it on my /books page and see what I’ve been reading and how my taste has evolved over time.

Outside of that, I’ve mostly traded video games for documentation at this point, which, depending on who you ask, is either growth or a warning sign.

The honest version

If you strip all of this down, the honest version is pretty simple:

I love building things.

Not in a vague, “it’s interesting” way. In a very specific, slightly obsessive way. The kind where you lose track of time because you’re chasing a small detail that most people won’t consciously notice, but they’ll feel it.

• Good design matters.
• Performance matters.
• Clean, readable code matters.

Not because it’s “best practice,” but because someone, whether it’s a user, a teammate, or future me, is going to interact with it. And that experience should feel intentional.

And yeah, That terrible movie-download website?

Still a little proud of it.

Because it did exactly what it needed to do.

It got me started.