I'm Krishna. If you're reading this, you probably already know I write code for a living, but I figured the actual story of how I got here is more interesting than a list of technologies, so that's what this post is.
The late start that didn't feel late at the time
Here's the thing most people don't expect when I tell them — I didn't start coding seriously until the final year of my graduation. I did my B.Tech in Computer Science Engineering, sat through years of theory, data structures, algorithms, the usual syllabus, and it wasn't until that last year that something actually clicked and I started building real things instead of just studying how things are built.
I don't say that as a regret. If anything, I think it gave me a strange kind of urgency that a lot of people who start at fifteen never get. I wasn't coding because it was a hobby I'd had forever — I was coding because I suddenly understood I had very little time left before I'd need to actually know how to do this for a living, and that pressure made me learn fast. I went from tutorials to actual projects in a way that felt almost frantic looking back at it, but it worked.
That said, my interest in computers and technology itself goes back a lot further than my final year — that part isn't new. I've been fascinated by how machines work since I was a kid, long before I understood any of the theory behind it. I just didn't connect that childhood fascination to "I could actually build this stuff myself" until much later than most people in this field seem to.
The internship that changed how I think about code
The real turning point for me was a six-month internship where I stopped writing code that just "works" and started writing code that has to survive contact with real users. That distinction sounds obvious when you say it out loud, but you don't actually feel it until you're the one on the other end when something breaks.
During that internship I worked on systems that handled around 100,000 users, which was the first time I had to think seriously about things like caching. Not caching as a concept from a textbook — actual caching, where the decision of what to cache, for how long, and when to invalidate it directly affected how fast the app felt and how much bandwidth we were burning through. Adding proper caching layers cut down latency in a way I could actually see and measure, and it also meaningfully reduced our bandwidth usage, which turned out to matter just as much from a cost perspective as it did from a performance one.
That internship is where I learned the difference between writing code and being an engineer. Writing code is making something run. Being an engineer is making something run for real users, under real load, without falling over the moment traffic spikes — and then explaining why it didn't fall over, because someone will always ask.
What I've actually built since then
Since that internship, I've kept building — a lot. At this point I've shipped more than a dozen full-stack and frontend projects, ranging from cinematic landing pages built around GSAP and scroll-driven animation, to full products with real backends, real databases, real payment integrations, and real users hitting them.
Some of these were built purely to learn something I didn't know yet. Others turned into actual working products I'm genuinely proud of. I've written about a lot of them in more detail elsewhere on this site, but the short version is that I don't really distinguish between "practice projects" and "real projects" in my head anymore — every one of them taught me something that showed up again later in a project that mattered more.
I've also spent some time contributing to open source. It's a different kind of humbling compared to building your own projects — you're not just solving a problem, you're solving it in a way that fits someone else's codebase, someone else's conventions, someone else's standards for what a good pull request even looks like. It made me a more careful reader of code, and a more careful writer of it too, because you can't hand-wave past sloppy work when someone else is reviewing it line by line.
What actually pulls me in
If you ask me what part of this field I find genuinely exciting, it's backend systems and distributed systems, specifically the question of how you take something that works fine for a hundred users and make it work just as well for a million. That problem never gets old to me. Every layer of it — caching strategy, database indexing, message queues, load balancing, how you shard data, how you keep things consistent when multiple services are all trying to touch the same piece of state at once — feels like a genuinely hard puzzle with real consequences if you get it wrong.
I think what draws me to this specifically is that the failures are so unforgiving. A frontend bug is usually visible and annoying. A backend bug at scale can take down an entire product for thousands of people at once, quietly, in a way that doesn't show up until it's already a problem. Learning to think ahead of that — to design for scale before you desperately need it — has become the thing I care most about getting better at.
Outside of the screen
I read a fair amount, and I listen to music pretty much constantly while I work — it's become part of how I think through problems, honestly. There's something about having music running in the background that helps we get into the kind of focused, half-distracted state where the actual solution to a bug shows up instead of when I'm staring directly at the error message trying to force it.
I don't think the "outside of coding" stuff is separate from the coding, really. Reading has made me a better writer of documentation and a better explainer of my own decisions. Both habits are just different forms of the same thing that got me into computers in the first place — genuine curiosity about how something works, taken far enough that you actually go find out.
Where this leaves me now
I'm still early in this, by most measures — a late start, one internship, a stack of side projects, and a growing pull toward the harder, more structural problems in backend and distributed systems. But I don't think "early" and "serious" are opposites. I take this seriously enough to keep building things nobody asked me to build, just to understand them better, and that's probably the most honest description of who I am that I can give you.
This site, and the rest of what I write here, is basically the ongoing record of that.