Skip to main content

The Story of My Career: A Conversation

· 18 min read
Irving Dinh

This post is a conversation between me and Claude Code, where I documented my entire career journey. I wanted to create a space to reflect on my professional story — all the details, context, wins, and challenges — before they fade from memory. A living document that grows as I grow.

The Beginning​

Claude Code: When did you write your first line of code (or get interested in tech)?

Irving: All of my programming journey started in my 3rd grade (about 8 years old), when my father opened a "net cafe" in my hometown. In those days, the internet was an unknown term — no one knew about it. Even though it was called a "net cafe", it was actually a LAN PC game center, starting with only 10 PCs. Looking back, that was my first exposure to the computer world, and my "programming" skill was about using cheat engines to search for money/health memory variables and modify them to cheat.

After a while, when I was around 14, my hometown got widespread internet access for the first time, and one of the most popular online games, Võ Lâm Truyền Kỳ, was released by Vinagame. Unlike other kids in my hometown, I got support to play the game hardcore from my parents. My father played the game too, and our home was one of the small number of houses that had ADSL back then. What did this lead to? Automation programming. We bought an automation tool to train the game character, but when the game was updated, it took a long time to update the tool. So I learned from the tool and started writing my own LUA scripts to do the trick myself.

This automation tool, just for gaming, contributed an important foundation for me about automation, PC setup for long-running tasks, VM operations for running automations that require full control of the mouse and keyboard, etc. for the later journey.

University and First Job​

Claude Code: What happened after the LUA scripting phase? Did you ever think "okay, maybe I should actually learn to code for real"?

Irving: Throughout my time at Van Lang University, I was lucky that they still had a partnership with Carnegie Mellon University, which gave us a program that wasn't just about programming — it was about all aspects of software engineering, from requirement techniques, to design, development, testing, and maintaining.

During the last semester, I had a chance to join an internship at Logigear, one of the famous testing agencies in Vietnam. Even though I started with mostly manual testing, I still had a chance to do some coding and automation testing with TestArchitect — a product of Logigear — to test WinForm applications, and also Selenium for web automation. And you can guess what happened: with my automation thinking skills from years of gaming, it took no time for me to master the tools, reach peak productivity, and bring my VM skills to my seniors, helping them go from 1 PC running 1 automation project at a time to 1 PC running 4 automation projects at a time. Those times were really good, and I learned a lot of things. But one of the downsides was that my manual testing time was still expected to be high, at about 80%. For a lazy guy who thinks extensively about automation, it wasn't for me anymore. So I moved out for another journey, where I could use my software development skills better.

YouNet Social​

Claude Code: Where did you go after Logigear? What was that first "real" software development role?

Irving: I didn't slow down — left Logigear on Friday, started at YouNet Social the following Monday. YouNet provided operations and customizations for customers who wanted to host their own social network website, like PHPFox or Social Engine. Even though I mostly worked with PHP, it took no time for me to realize the chance for improvement. There were 3 biggest improvements I brought there.

The first one: the team used to use FTP to deploy changes directly to the customer's host by literally dragging the files and folders there. My university friend and I, both working there, introduced Jenkins for automated deployment for the first time. Funny how the tool used by DevOps and SysAdmins the most was brought to the company by 2 junior devs 😄

The second one: back then, PHPFox and Social Engine both used SCSS/LESS as CSS preprocessors, but the converter was PHP, and it literally took more than 10 minutes to convert all to CSS to make changes visible in the browser — way too long. Once again, I brought Node.js into play and tuned it up to replace the PHP CSS converter. The change now took under 30 seconds for the dev environment, improving the developer experience to the next level.

The third one was for UI/UX. With PHP and AJAX, it was still a bit hard to do small interactions within the page to improve the user experience. I couldn't stay with that boring setup and introduced the way to integrate Vue into PHPFox's boring pages. It was like a new chapter for development, opening many possibilities.

But once again, I found that YouNet was a bit slower in technology adoption, and the challenge wasn't enough for me to enjoy, so I moved out just after one year of many breakthrough contributions.

Sendo: E-commerce Scale​

Claude Code: So what was next after YouNet? You said the challenge wasn't enough — where did you go to find bigger problems to solve?

Irving: After leaving YouNet, I joined Sendo — one of the biggest e-commerce platforms in Vietnam at that time.

Their system was backed by a Magento website, then migrated into Read-and-Write services (using Go), and was in the process of migrating to microservices. I joined the customer management team, where they chose to go with Node.js-based applications due to some political reasons. The technical lead of the team then left, and my team fell into a human resource exhausted situation — and this is where I grew.

After consulting with the EM and some higher-ups, I got permission to restructure all the services for customer management — as a 3-year experience software engineer. I had a chance to work with all the stuff, with all the technical and business teams in Sendo. I helped place the infrastructure for not just the Go microservices, but also how we centralized the logs and metrics across the VMs (yes, we didn't have k8s back then), wrote the runbooks for the microservices, integrated across teams, and got through high-intensive flash sale events with a bunch of issues — from the service itself to the Redis network bandwidth exhausted issue.

I also did what I do best: improving the developer experience by introducing a full-stack developer internal tool to quickly do some operations. I spent 2 years at Sendo — double my previous stints.

Claude Code: Tell me more about the Redis bandwidth issue during flash sales and the internal developer tool you built.

Irving:

  1. It was all about my custom plugin for the nginx gateway, where I wrote a small LUA script (guess what — from the very long-ago gaming automation tool knowledge) to check the session header and embed the basic user information into the request before reverse proxying it, so the services had no need to do the same again. The problem was that during the sale event, the 5Gbps connection between nginx and Redis wasn't enough. We then modified the hardware to adjust it to 20Gbps to serve the large amount of requests. I didn't do the hardware change, but staying there with the sysadmin team was a wonderful experience.

  2. The internal tool was about automating tasks we needed to do every day for the development/production environment, and also a first step for the customer support team to use. One example was a tool for our marketing team to send app notifications to customers more easily instead of going to the Firebase console each time. I also worked with the order management team, marketing team, and event team to provide the tools/APIs they needed to serve operations, events, and customers.

Grab: Learning from the Best​

Claude Code: What came after Sendo? You were clearly on a rocket ship trajectory.

Irving: I then had a chance to work for another big name: Grab. Actually, I found the political culture wasn't fitting anymore at Sendo, so I decided to look around. I got support from my bestie in Talent Acquisition to join Grab in Ho Chi Minh. And with Grab, I no longer shined — I became a learner again, as there were tons of rockstar developers there!

I joined the post-ride team and took responsibility for the services for cancellation and feedback, with a small team size (3 SWE, 1 EM). I didn't do any big thing at Grab, as they were super well-defined. I was so lucky back then to learn from the best — from coding, documenting, to deploying, and also the developer experience. Everything was so exciting.

It was the first time I experienced a "monorepo" for all the Go services at Grab. It was a super convenient way to understand what was happening and learn all the logic without asking others too much. I also learned the right way of CI/CD with plenty of money invested into the tooling back there. I learned how to write correct and useful unit testing/integration testing and did proper load testing with full tooling support. I also learned how wonderful GrabKit was — a dedicated framework designed by Grab for Grab — and until these recent days, my coding styles and thinking styles are still affected by this framework. I also learned the super thoughtful developer experience of configuration management and deployment management. The talents team at Grab actually developed a dedicated tool to deploy services, canary deployment, rollback easily — all by themselves. And don't get me wrong, the UI/UX of that tool was kind of top-notch level. There weren't many SaaS tools back then as good-looking and easy to use as our deployment tool.

Claude Code: What specifically stuck with you from GrabKit? And did seeing Grab's tooling change how you think about developer experience?

Irving:

  1. It's a huge amount of things, but what stuck with me the most is the abstraction. It taught me how to do a "proper framework" with Go — which prioritizes being unopinionated, but that also hurts when you have 10, 100, or 1000 engineers. Until today, my lib/framework for Go services is super opinionated, especially the common ones. The philosophy is very simple: when you're writing new services, you don't want to reinvent the wheel. You want to focus on business logic only — not think about how to log, how to track metrics, how to load config, how to structure files, etc. And it's even worse if you're working with 10 services with different approaches each.

  2. Yes — at the very least, how seriously I'm putting effort into tooling, and it made me seriously think about developer advocacy. I spent 2 years at Grab soaking it all in.

Highlands Coffee: Building from Scratch​

Claude Code: What came after Grab?

Irving: After 2 years at Grab, I left for another greenfield opportunity — a place to apply what I learned from Grab. And I spent another year at Highlands Coffee, one of the biggest coffee chains in Vietnam, to rebuild from scratch the integration infrastructure for online food delivery services like Grab, Shopee, and Be Vietnam. It was literally rebuilding from scratch the entire POS system, from the ground up, with the best-in-class things I learned: Terraform, CI/CD with Azure DevOps, Go framework, etc.

It sounded like working for a startup — a small tactical team — but with plenty of money backed by a big enterprise. This is where I learned a lot, especially understanding how to make a system that serves the busyness of a coffee chain. Every single fraction of the interaction must be tailored to help the brewer, the waitress, the store manager to work with the system effortlessly — not making their job harder.

Claude Code: How did that change the way you think about building software? At Grab, your users were engineers. At Highlands, your users are baristas in the middle of a rush.

Irving: It's a lot of stuff to think about:

  1. On the infrastructure side, not only the cloud infrastructure must be maintained, but also the local server at each store needed to be considered in case there's no internet connection — which was rare, but thinking about it was worth the effort.

  2. On the backend side, I needed to consider all the solutions to make connections stable and responsive, from server-side rendering, to socket.io consideration, and also bidirectional gRPC. From a screen for the store cashier to the barista to the guest catching up with all the orders going on in the store. Also displaying the orders from food delivery and helping the store manager interact with orders within one table/device, instead of the POS device and 3 other phones/tablets, each for a food delivery service — which, sadly, I didn't make happen by the day I left Highlands.

  3. On the frontend side, I needed to get rid of my minimal, clean UI design and get back to the UX side, which must be learned from the actual cashiers who manage multiple orders at a time, from in-store to online services. Learning from how their hands move, how their eyes look at the customer then look down — or even not look at the screen — then make the interaction to create the order, etc. This was a very interesting experience, and the staff at Highlands were very well-trained, so they helped me a lot in learning these things.

  4. Also, besides working with the store, I worked with the operations/marketing team to get them to know about the system and get feedback on how to generate useful reports for them to easily catch up with sales status.

Axon: Fortune 500 IAM​

Claude Code: What made you leave Highlands, and where did you go next?

Irving: After a year at Highlands, I decided to leave the company even though I still had a lot of ideas to pursue — one reason being that top-level priorities changed a lot and changed frequently. And also, I found another company where I spent 3 and a half years: Axon.

At this business-first Fortune 500 company, I joined the platform — identity access management team, which controls authentication, authorization, session management, user and user's organization management. And I experienced the lessons of how to make and operate top-tier highly available services (like 99.99% uptime services).

Some of my highlight projects were: a risk-based authentication system to allow users to remember their login information — which is super critical, as my users were mostly US police; using Axon's body camera as an OTP device instead of using SMS, email, or app-based OTP devices; an internal admin system for customer support usage to aid users; and advanced user automation provisioning service (manual importing, Active Directory on-prem sync, and SCIM).

Besides the broad Terraform, Scala, Go, TypeScript (Node.js/React.js/GitHub Actions) development, most of my time wasn't in development/coding, but in operations. We spent a lot of time on designing and especially on-call to ensure the services were okay. I got into maintaining the runbook, making myself familiar with the deadly 😅 on-call rotation — the whole week of light-sleep and ready at 3am in the morning whenever an alert was triggered, and they triggered a lot. Whether it was noisy or not, I needed to treat it super seriously due to the impact of the services.

The most I learned at Axon was not from the infrastructure or the system, but from the people. The team there was all the best people — besides the ones at Grab — I've luckily worked with. They had points, views, and perspectives that were different from mine. They asked question after question until the problem was clear as daylight, and saved me from a lot of stupid decisions.

Claude Code: 3.5 years is your longest stint! What made you finally leave Axon?

Irving: The critical thinking was in their blood — they wouldn't let me do anything until I cleared all of their concerns, which helped the system stay up with its critical responsibility.

In the ending period at Axon (about half a year), I found:

  1. I had experienced a lot with AI, and I play with AI daily. From making a personal mobile app about AI, to applying AI into my daily life (like this very conversation). I spent a lot of my fortune on AI in the belief it would help me do something impossible from my previous period of time — and it did. I really, really wished I could introduce AI into Axon's workflows to help me and my teams improve productivity. But it was way too hard, as there were a lot of blockers in resources, policy, etc. I would have done it personally and hacked a way, but Axon isn't Sendo — it's a global and top-tier policy-respecting company.

  2. I saw I had no room to improve, as I'm someone who loves to produce, not maintain. But operational excellence took about 95% of my effort at work, and another 5% was even heavy context switching to support the on-call rotation, or just the echo of the on-call rotation. I found I had nothing to improve in the whole 3 years at Axon. At the last moment, I found something fun but got a blocker, so I needed to go somewhere else to help myself — even though the team there was like my 2nd family.

I will tell you about another marvelous journey of mine — how I improved myself personally, even at companies where I couldn't improve much, like Grab and Axon: it's my side projects.

Side Projects: The Real Growth​

Claude Code: Tell me about those side projects. What have you been building on your own time?

Irving:

  1. Back during the transition from YouNet to Sendo, I worked with my university best friends on another gaming project — this time Counter-Strike: Global Offensive. We got some offers from a cyber gaming center in Ho Chi Minh city that wanted to create competitions for the community. We bought the csgo.vn domain, wrote a CLI to connect to CSGO, built a nice web interface for matchmaking and map ban/pick, just like a real competition. Back then, we had Laravel for the backend, socket.io for real-time interaction, Go in the CSGO server, and React.js for the UI. Not stopping there, we went further to have an Asia-wide competition, where I read the logs of the CSGO server to help display real-time update webpages, including a near-realtime map with all the players playing around — displayed in the venue beside the caster camera.

  2. After the CSGO project (ran out of funding 😢), I left my friends and made some small, hyper-casual mobile games with Unity to publish to the Apple App Store and Google Play Store. It wasn't much — just for me to train a bit about game development and art designing.

  3. After the mobile games, I also made some small utility mobile apps with not too many users. I decided to go and learn UI/UX design, where I gained a lot of thinking as a product designer and product manager. It not only helped me in working on my own applications — it also helped me understand my designers and product managers during my work at Grab, Highlands, and Axon.

  4. After a dozen failed utility apps, I stepped into the era of AI. I made an AI chat app with multiple models for users to chat without buying different subscriptions — but it failed due to high workload at Axon. Then I moved to an AI image maker and editor, but it also failed due to high workload at Axon, and the costs increased to a level where ads couldn't cover it. Also another workflow for AI models to help — but it failed from the idea phase when Google introduced the same idea and gave it away for free. Even though they failed, they helped me build my solid infrastructure and mindset to build up the AI I use until now and far more into the future.

Looking Back and Moving Forward​

Claude Code: Any regrets looking back at 10+ years?

Irving: I just wish I had documented my career a bit sooner — I think it would have been wonderful and helped me a lot today. But it is what it is. I don't regret it. I realized it now and wish I can keep the curiosity and the continuous attitude until I die — just like what I've done is enough for me.

Current Status​

I'm currently taking a break and immersing myself in the ocean of possibility of AI ideas full-time. After leaving Axon, I chose to go deep into the thing that excites me most.

The journey continues.