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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.