My Story
I studied mechanical design, manufacturing, and automation at university. I first wrote code because some tasks in the games I played were unbearably repetitive. I figured out enough Lua to write scripts that would do them for me. It wasn’t a serious career plan. I just wanted to skip a few rounds of grinding.
Before graduating, I spent three months interning at an auto parts company, testing the strength and tensile properties of different materials every day. There was plenty of repetition there too, but at the time I couldn’t see a way to make that work simpler. I left before the internship turned into a permanent job.
I kept thinking about what to do next. Around then, the game accounts and equipment I’d earned with my scripts were selling well enough to make me my first real money. I thought: if I enjoy tinkering with this so much, why not learn to program?
I spent about a month teaching myself, then kept learning while looking for work. Without a computer science degree or experience, most of my applications went nowhere. My strategy was to apply widely, let companies screen me first, and talk properly with the ones willing to meet. Once I even walked into a software company that wasn’t hiring. The owner interviewed me anyway, then said, “I admire your courage, but we need someone with experience.”
Eventually, a startup in Hangzhou gave me a chance. I became its first programmer and learned on the job while shipping our first product. It let people select text to get a translation and explanation. That sounds like a small feature now, but getting text selection right kept me wrestling with regular expressions for ages. I’m still grateful to the founder who trusted me with that opportunity.
Hangzhou felt young and intensely competitive. The mobile internet boom was in full swing, and everyone around me seemed to be racing ahead. I felt anxious too. I was learning quickly on my own, but I wasn’t sure how far I still had to go to become a mature developer. So I joined Dahua to see how a more established team worked.
There, the shared components I built were reused by many departments. Getting a feature to work for me was one thing; making it work well for all those teams was another. Different situations demanded different trade-offs between performance and ease of use. I learned a lot, but I didn’t enjoy the atmosphere around me. In my part of the organization, there was also overtime that felt unnecessary, long meetings, and people passing responsibility around. That was part of why I left.
I moved to Suzhou to work at Siemens. Life there moved more slowly than in Hangzhou, and I enjoyed having a better balance between work and the rest of my life. I lived through the pandemic there. Later, I came to New Zealand on a Working Holiday Visa. I fell for the scenery and the people I met, and soon decided I wanted to stay.
Finding opportunities didn’t feel too difficult at the time. Speaking English on the phone was another matter. Sometimes I could barely follow what someone was saying, but felt too embarrassed to keep asking them to repeat themselves, so I just said, “OK, OK.” Once, before I’d even worked out what stage our conversation had reached, I received an internal welcome email the next day. I had to go back, explain the misunderstanding, and turn down the offer.
In the end, I chose Nextspace. Its 3D digital twin world felt a little like working on a game, while still connecting to the industrial systems I’d worked with before. Being fully remote appealed to me too. After finding the job at Nextspace, I was granted a Straight to Residence Visa and became a New Zealand resident. Looking back, it feels as though New Zealand and I were meant to find each other.
I started as a software engineer working across frontend and backend, with more of my time on the frontend. After a while, I began to think that AI could do something interesting with the digital twin, so I put forward a proposal. We built on that idea, and it led me deeper into agent development.
Digital twins hold a lot of messy data. Say someone wants to find buildings in a particular city, built within a certain period, whose emissions exceed a threshold. Before, they would have to assemble the search conditions themselves, highlight the results in the 3D scene, and perhaps prepare a report. I started using agents and MCP to connect the search, scene, and reporting tools, so people could begin by describing what they wanted. I also see a business case: if data is easier to find and use, customers may be more willing to bring more of it into the platform and keep using it. That fits a product model measured by the scale of data and entities managed.
I’ve long been interested in blockchain, cryptocurrency, and investing. I’ve spent time around Web3 and invested in Bitcoin. I’ve also written scripts to monitor and collect news, then automatically trade digital assets according to rules I set. Speculation is probably a more honest word than investing for some of that. Having made those decisions myself, I wanted a more systematic understanding of finance and risk instead of relying on instinct. So while working at Nextspace, I completed a master’s in FinTech and Investment Management at Lincoln University.
By chance, I later began working as an agent integration consultant at Dynamic Payment as well. AI helped me a lot while I was studying alongside my job, and later while balancing two roles. These days I use AI assistants for work, shopping, bookkeeping, scheduling, and even some social communication. During my master’s, I used lectures to get the broad outline, then worked through much of the material by asking AI questions, talking through ideas, and checking my understanding afterwards.
I know some software engineers are wary of AI. My own feeling is mostly gratitude. I don’t think it makes software engineers unnecessary. My guess is that, as building software gets easier, more small teams will start making products, and more engineering problems will appear with them. AI can already take an idea to ninety percent quite quickly, sometimes even to what the original brief called one hundred percent. But once people actually use a product, it still has to be reliable, easy to work with, and able to handle situations nobody thought to specify. Making it better than the original brief takes engineers who understand the business and know how to make trade-offs.