Experience

One thing has always had a habit of leading to another.

Twenty years of building things, the road that connected them, and the toolbox I picked up along the way.

I started close to the silicon, with physical design. Then I wanted to automate the work. Automation pulled me deeper into software. Software wandered into the cloud, met production systems and the web, and eventually found its way into architecture and AI.

Not all of it happened at work. Some things I learned because I needed them, some because I was curious — and every now and then, something I picked up for fun opened the door to what came next.

So this isn’t really my résumé. It’s the trail of things I picked up, built, broke, learned, and carried forward. Here’s how they connect.

The road so far

  1. 2003 — 2006

    Intel

    Philippines

    Physical Design Engineer

    Where it starts — in silicon rather than software.

    Full-chip layout on flash memory products, working to constraints that are physical rather than logical: area, timing, manufacturability. I led four full-chip projects, which was the first time the work was as much about coordinating a system of dependencies as about the engineering itself.

    The other thing I remember has nothing to do with layout. The team needed somewhere to keep documents, so I built one in PHP and MySQL — picked up on my own time, at a job that had never asked for it. That turned out to be a pattern.

    • IC physical layout
    • DFM and verification
    • EDA tooling
  2. 2006 — 2011

    Chartered Semiconductor / GlobalFoundries

    Singapore

    DFM and Design Methodology Engineer

    I stopped doing the design and started building what designers use.

    Design kits and technology files across a long run of process nodes, and the reference-flow work that decides how a design flow behaves before anyone runs it.

    This is where automation became the job rather than a convenience. Scripting a flow, checking it, and making the results repeatable is a different discipline from designing the chip — and it is the one that carried forward into everything after. Three papers came out of these years, on physical verification and lithography inside the design flow.

    • Tcl
    • Perl
    • Python
    • Linux and UNIX
    • EDA tooling
    • RTL-to-GDS flows
    • DFM and verification
  3. 2011 — 2012

    Plunify

    Singapore

    Design Engineer, Software Applications

    Then cloud entered the picture — in 2011, which was early for EDA.

    A start-up, and the first cloud work: an API that let EDA software run on AWS, and the backend automation carrying a customer’s design from their desk to the cloud and back. Fully parallel design-space exploration and timing closure, which ended up as a co-authored paper at DAC 2012.

    Short, and disproportionately formative. It established the instinct that compute is elastic, and that the interesting constraint is usually orchestration rather than capacity.

    • Tcl
    • Perl
    • AWS
    • Linux and UNIX
    • FPGA tooling
  4. 2013

    NYSE Euronext

    Philippines, offshore

    Production Engineer

    Only a short stop, but it permanently changed how I think about failure.

    A year outside semiconductor, on market-data systems where an outage is measured in money. Monitoring automation, rollouts, and the investigation work when something broke: backtraces, log tracing, capacity review, server tuning. The task I remember best was unglamorous — cutting false alerts by going through each one’s timing, the binary behind it, and the algorithm that raised it. An alarm nobody trusts is worse than no alarm.

    I got this role largely on Linux I had taught myself at home. Owning something in production teaches you to design for the day it fails, and that is a habit rather than a technique.

    • Perl
    • Shell and Bash
    • C++
    • Linux and UNIX
    • Monitoring and diagnostics
    • Networking
  5. 2014 — 2024

    GlobalFoundries

    Singapore

    Principal Software Automation Engineer

    A decade where the separate threads finally became one job.

    Execution frameworks for semiconductor manufacturing workflows, enterprise web services, integration APIs, workflow monitoring, centralised credential management — systems architected from a blank page and then owned in production as the person called when they broke. Underneath sat the unglamorous plumbing: queue-driven processing, event handling, asynchronous execution for anything long-running.

    One project pulled on the whole career at once. A metrology application I took over was not producing good results, and fixing it needed the IC design knowledge from 2003, the software engineering from every year after, and a machine learning approach to something conventional methods handled badly. Ten years of living with what you build is the part that changes how you design.

    • Python
    • Tcl
    • Linux and UNIX
    • AWS
    • REST APIs
    • SOAP services
    • Django
    • NGINX
    • MySQL and MariaDB
    • JSON, XML, YAML and OData
    • Microservices
    • Monitoring and diagnostics
    • Git
    • CI/CD
    • Machine learning
  6. 2024 — present

    Synopsys

    Ontario, Canada

    Senior Staff Software Engineer

    Back to design automation — with a much bigger toolbox this time.

    Design automation again, at the tool end rather than the foundry end: workflow automation for circuit design, collateral generation and validation, staging and release automation, and the frameworks underneath them. Agile practice around it, and the slow work of raising release quality across a shared codebase.

    And AI-assisted development as a working method rather than a demo. That is the thread this site is currently about, and it isn’t a pivot — it’s everything above, pointed at a new class of tool by someone who has watched a few waves of engineering tooling arrive and knows which questions to ask of this one.

    • Python
    • Tcl
    • HSPICE
    • Custom Compiler
    • EDA tooling
    • CI/CD
    • Test-driven development
    • Unit, SIT and UAT testing
    • Agile delivery
    • Git
    • AI-assisted development
    • Prompt and context engineering

Skills — Things I picked up along the way

Some of these arrived because a project needed them. Some I went and learned because they looked interesting, and turned up at work later. No percentages and no dates — just whether I still reach for them.

Languages

  • Python
  • Tcl
  • Perl
  • Shell and Bash
  • SQL
  • PHP
  • JavaScript
  • TypeScript
  • C++
  • Java
  • C#still learning

Systems and cloud

  • AWS
  • Google Cloudexploring
  • Linux and UNIX
  • Apache
  • NGINX
  • Heroku
  • Virtualisation and sandboxes
  • Networking

Web, services and data

  • REST APIs
  • SOAP services
  • Djangonow and then
  • Astro
  • Microservices
  • MySQL and MariaDB
  • JSON, XML, YAML and OData

How I work

  • Git
  • Perforce
  • CI/CD
  • Test-driven development
  • Unit, SIT and UAT testing
  • Agile delivery
  • Monitoring and diagnostics

Semiconductor and EDA

  • EDA tooling
  • RTL-to-GDS flows
  • IC physical layout
  • DFM and verification
  • HSPICE
  • Custom Compiler
  • FPGA tooling

What I am exploring now

  • AI-assisted development
  • LLMs and local modelsexploring
  • Agents and multi-agent workflowsexploring
  • Model Context Protocolexploring
  • Retrieval and knowledge systemsexploring
  • Prompt and context engineering
  • Machine learningexploring

Outside the day job

  • Web work

    Learned for fun, and it keeps turning up at the day job.

    The oldest thread here, and none of it was ever anyone’s job description. It started with PHP and MySQL and has stayed a side practice ever since: freelance system administration, small business sites, custom applications for people who needed one thing built properly. A church management portal is the current one, along with this site.

    • PHP
    • MySQL and MariaDB
    • JavaScript
    • TypeScript
    • Astro
    • Apache
  • Linux and sandboxes

    Where things get broken on purpose, so they don't get broken by accident.

    Certification, and the many hours behind it — filesystems, SELinux, LAMP, kickstart, virtualisation, and enough networking to be useful. No employer taught me production Linux administration; I learned it on my own hardware, and it is a large part of why a production engineering role was open to me at all. Local sandboxes and unfamiliar distributions are still where anything risky gets tried first.

    • Linux and UNIX
    • Shell and Bash
    • Virtualisation and sandboxes
    • Networking
  • The cloud lab

    I'd been using AWS for years before I sat down and properly studied it.

    There is a difference between using the services a project happens to need and understanding the platform, and for a long time I had the first one. So: courses, then experiments. The output is a small demonstration platform built to prove to myself I could assemble the pieces unaided — compute, identity, storage, queues and notifications wired into something loosely coupled that actually runs.

    • AWS
    • Google Cloud
    • Linux and UNIX
  • The AI lab

    This line of the toolbox got long rather quickly.

    Not a course this time — projects. Agent workflows, skill and tool systems, retrieval and knowledge stores, local models, Model Context Protocol servers, and a steady stream of small tools built to answer one question each.

    The problem I keep circling is that an agent starts every session knowing nothing about your project. That’s what KAE is about. It is a learning journey and I’d rather say so: some of these experiments did not work. What I’m sure of is narrower — the judgement about what to build, what to verify and what to throw away is still the scarce part, and it came from the twenty years above.

    • LLMs and local models
    • Agents and multi-agent workflows
    • Model Context Protocol
    • Retrieval and knowledge systems
    • Prompt and context engineering
    • Machine learning
    • Python

You've reached the present.

The rest is still being built. There are twenty years of specifics behind everything above, and most of them are more interesting as a conversation than as a paragraph.

For the formal history, there's LinkedIn. For the parts that don't fit into either a timeline or a job title, you'll have to ask.