I got interested in computers in sixth grade, at Sunrise Boarding School in Kathmandu. The lab had black-and-white CRT monitors and floppy disks, running Windows 95. The first class was MS-DOS — typing commands into a blinking cursor and seeing what happened. That’s where my interest in how a machine actually works started, not just what it could do for me.
Seventh grade moved into Microsoft Office — Word, Access, Excel, and Paint. The monitors were still black and white, so in Paint, white stayed white and black could be set to any other color we picked. We’d draw in it anyway and call it art, which in hindsight was a fairly strange way to learn color.
Eighth grade moved into Visual Basic and VBA, and we built a school scoring and transcript system in Access that year — grades going in, transcripts coming out, with VBA running behind the forms.
A few years later the internet showed up, mostly through cyber cafés. Around 2006, you paid by the hour to sit at a shared computer, check Yahoo Mail, and use Yahoo Messenger — often to talk to friends I’d already seen at school that same day. Getting online at all was still a big deal then.
School kept building on that. We covered QBasic and basic algorithms, and later, in high school, computer science was offered as an elective — not required, and not popular, since it added hours on top of an already full science and math schedule. I took it anyway, with a few friends, and that’s where I first learned C and C++.
That interest turned into a scholarship to study in the US, at Oklahoma State University Institute of Technology, for a bachelor’s degree in Information Technology with a software development major. A visa requirement meant I needed on-campus classes beyond the mostly-online software curriculum, so I picked up Network Administration and Information Security Assurance as a minor. It ended up shaping how I approach every system I’ve worked on since — understanding networking and security directly, rather than treating them as someone else’s job.
The degree covered a wide range: Python in the first year, PHP and JavaScript for web development, then SQL and database management alongside the security coursework, and finally C# in an enterprise application development course that led into a capstone project. That range mattered more than any single language — seeing a system from the network layer through the database to the application code is what makes it possible to debug someone else’s twenty-year-old application instead of being intimidated by it.
Twelve years into the industry now, most of that work has been on systems that were already old when I started on them. I got my first internship at MicahTek Inc. right after OSUIT, and went full-time there after graduating. A few months into the role, several senior developers left, and I took on responsibility for the database, a legacy ecommerce and CMS platform built in ColdFusion, a scanner application, a call-center application, and the day-to-day production issues surrounding them. Documentation was limited, so I learned to trace behavior through the database, application code, and business workflows themselves. That experience made me a more resilient developer — comfortable entering unfamiliar systems, diagnosing production problems, and finding answers without needing every step explained first. Later at MicahTek I also worked on legacy platforms like Pick BASIC and UniVerse multi-value systems, along with older PHP applications carrying years of undocumented business logic.
At Clicks Web Design Inc., I started by supporting a PHP-based system before moving into production Angular development. I hadn’t worked with Angular before that job. I came from Vue and Nuxt.js and already had a solid JavaScript background, so picking it up and becoming productive in the production system didn’t take long. My development manager had decades of industry experience, and working with him strengthened how I approached code reviews, production engineering, maintainability, and mentoring other developers.
That’s not the kind of work a technology degree fully prepares you for. It’s reading code nobody has touched in years, figuring out what the business actually depends on before changing anything, and making old systems work like new ones without breaking what already works. Most of it wasn’t greenfield, and I think that’s made me a better engineer than if it had been.
Now there’s AI, spec-driven development, and a rapidly changing generation of development tools. My take is straightforward: none of the fundamentals I picked up along the way — MS-DOS as a kid, C and C++ in high school, networking and security through an unexpected minor, twelve years of reading other people’s legacy code — matter less because a model can write code faster than I can type it. They matter more. A model can generate a plausible-looking migration for a Pick BASIC subroutine in seconds. Whether it’s correct still depends on someone who understands the system well enough to know what “correct” means for that specific business, and who checks it before it ships. That’s not something a tool gives you. It’s something you build up over years of working through systems like this.
That’s also why spec-driven development makes sense to me. Before asking AI to produce code, I try to define the behavior, constraints, data flow, failure cases, and what success should look like. Then I treat the generated code the same way I would treat code inherited from another developer: read it, question its assumptions, test it against the real business rules, and verify what happens when something fails. The tools are new, but the engineering habit is familiar — understand the system before trusting the implementation.
I don’t know exactly where this AI era takes the industry next. But the same habits that got me here — understand how something works before changing it, define what correct means, and verify instead of assume — are the ones I’m relying on to navigate whatever comes next.