About
Hi, I'm Eason. I've been writing software since finishing my degree and my military service, coming up on thirteen years now.
Waigha & Unitech2013 – 2016
The first few years were at Waigha and Unitech, both in the barcode business. The work was building custom systems to whatever a client asked for, across PC, web, Android and handheld devices. A bit of everything, and that is where the fundamentals got drilled in: the languages, and the way to think a problem through.
QNAP2016 – 2021
Then five and a half years at QNAP, where my coding improved a great deal. As the projects grew larger I came to understand why architecture matters: design it well and you save yourself a lot of refactoring later, and the difference in performance is significant. Since then I have not rushed into writing code. I work out how the data should flow and where the boundaries sit first. Around the same time I started setting up environments myself, from Linux on-premises to AWS in the cloud. Doing it yourself teaches you that finishing the code is only half the job; if the machines, the network and the deployment are not right, it still will not run.
The other thing QNAP taught me was communication. Because I owned the customer service platform, I spoke with the support team every day and often dealt directly with the problems users reported. I learned to structure a conversation, using STAR and the like, and the cost of communicating dropped noticeably. The habit has served me well ever since, with PMs, with managers, and with clients.
Zerologix2021 – 2024
At Zerologix I mainly maintained the company's client portal and the internal admin system. That was where I came to appreciate how much documentation and records matter. The platform was an old project: no unit tests, patchy documentation, and a lot of business logic that no one could account for any more. Every change was nerve-racking, because you were never sure what else it would touch. Beyond reading the code line by line, the only way forward was to ask, PMs, managers, sales, marketing, the boss, and it was asking my way around that put the shape of the system back together.
A little over a year in, I took over as team lead, with nine to twelve people. It was my first management role and a real challenge. Inside the team there was plenty to learn: developing people, allocating work, tracking progress, running code reviews, gauging what the team could actually deliver, and standing in front of them when something went wrong. Outside it, the job was working through requirements with PMs, the boss and other departments, judging what was feasible and setting priorities. I wrote less code over that year and a half, but the way I saw things changed completely.
Chuan Heng2024 – Now
I am now at Chuan Heng. The company's core business is electrical and low-voltage engineering, and the software it needed used to be outsourced, so there was no in-house development to speak of. Since joining I have taken on everything from the servers and the backend through to the app and the IoT device side.
What is hard here is not only the application architecture but the operational one. Features keep iterating, and each new one means deciding up front which data can be shared and which should stay separate. Once there are a number of machines, connectivity, monitoring and deployment all need a standard of their own. Settle none of that early and it only gets messier with every patch.
Nearly thirteen years on, what has accumulated is more than languages and frameworks. It is the ability to solve a problem, to find a way through however tight the constraints. But I care about more than getting a problem off the table; I care whether it was solved cleanly. The documentation kept, the decisions written down, so that whoever picks it up next has something to follow.