From QBasic to production systems: how I got into software engineering

Most of what I write here is technical: backend design, cloud infrastructure, debugging stories from production. This one is different. It’s the story of how I ended up doing any of that in the first place, because blogging for me was never meant to be only about the technical side. It’s also about the path that got me here, and I want to write that down properly at least once.

It starts in a computer lab at Hetauda Academy, my school back home. We had a QBasic class, the kind every student in that batch went through, mostly typing along with whatever the teacher wrote on the board. I don’t remember the exact program anymore, something small, probably a loop that printed numbers or asked for your name and greeted you back. What I do remember is the moment I ran it and it actually worked. Not “worked” in the sense of matching the textbook, but worked in the sense that I had written a set of instructions, and a machine had followed them exactly, no more and no less. That was the moment I knew I was made for this. I didn’t have the language for it then, but that feeling of cause and effect, of writing logic and watching it hold, never really left.

After school I went to Golden Gate Int’l College for my +2 in physical sciences, which in Nepal’s system is less a declaration of intent and more a way of keeping the door to engineering open. It worked. I got into Kantipur Engineering College under Tribhuvan University for a B.E. in Computer Engineering, and that’s where the QBasic curiosity turned into something structured: data structures, algorithms, databases, actual software engineering rather than a school exercise. College is also where you find out whether you liked the idea of programming or the practice of it. I liked the practice more the further I got into it.

My first job out of college was as a PHP developer at Keroneva Design in Kathmandu, building custom web applications and CMS solutions. This is where the real learning started, because writing code for a class and writing code that other people depend on are not the same skill. I remember the first time I fixed a genuinely bad N+1 query problem and watched a page that used to crawl suddenly respond instantly. It’s a small thing in hindsight, but it was the first time I understood that software engineering isn’t just “does it run,” it’s “does it run well, for real users, under real load.”

Around a year into that job, I started working remotely for a US-based company, Maven Solutions, as a full stack developer, which meant close to a year of juggling both roles across very different time zones before I moved to remote work full time. That stretch taught me a different set of lessons: building real-time features with WebSockets, profiling and caching to claw back real performance gains, and probably the most important one, taking a codebase with zero test coverage and dragging it up to something like 72%. Nobody hands you a lesson plan for that kind of work. You learn it because the alternative is shipping something you can’t trust.

In 2022 I joined readytowork, Inc. in Tokyo as a Senior Software Engineer, later taking on a junior manager role as well. This is the chapter I’m still in, and it’s been the one where the scope of the work changed the most: architecting backend services and cloud infrastructure on AWS and GCP instead of just building features inside someone else’s architecture, and leading engineers across product lines instead of only leading myself. One of the bigger technical shifts in this chapter was moving from PHP to Go, which I’ve written about separately on this blog because it deserved its own post. I’ve shipped things I’m genuinely proud of here, like the Election 2082 Portal, and worked on cutting API p99 latency by 60% through query optimization, which is the kind of unglamorous work that only shows up in a graph nobody outside the team ever sees. The Reliability Award I got in 2025 mattered less to me as a trophy and more as a signal that the unglamorous work had actually paid off.

None of this was a straight line, and I don’t think most careers in this field are. But when I trace it back, it does connect: a kid in a school computer lab in Hetauda who liked that the machine did exactly what he told it to, all the way to someone shipping production systems for a company in Tokyo. The feeling from that first QBasic program still shows up now, usually at strange hours: the moment a stubborn bug finally makes sense, or a system you designed holds up under load you weren’t sure it would survive. It’s the same feeling, just with higher stakes.

So that’s the other half of what this blog is going to be. Alongside the backend deep dives and the debugging postmortems, I’ll write about the career itself: how I got here, what changed my mind about things, and what I’d tell the version of myself sitting in that computer lab if I could. Both halves are the actual point of this blog, not just the technical one.