Every number below is traceable to a source. Open any project card for the detail behind it.
Every bar maps to a specific project and its commit history — none of this is self-assessment. Click a capability name on the left to filter the project list below down to the evidence for it.
The last row is not a technical skill — it is “radius of influence”. Every segment in it has a counterpart outside my own department: our own senior executives, the customer's platform team, the customer's product design team, other departments inside the company, and the manufacturing (MP) organisation. A contract manufacturer's software team normally only faces the customer's manufacturing and test engineering window. These segments show that my surface area was wider than that narrow window. The two manufacturing segments are worth calling out separately: line equipment automation and automated optical inspection both served the MP organisation, not my own department. The users were the production lines, and the savings sit in the line-headcount ledger — a different book from the department-engineering-hours ledger used by the tooling group below. The same pattern shows up in the tooling group below: 7 of the 24 internal tools have users outside my department, about 16% of total benefit — those are the ones I had no authority over and could only land by making the tool genuinely good.
Filter with the controls below; click a card to expand the detail and links. Role labels come in four kinds: wrote it myself, architecture call, led the delivery, personal work — I do not count code my team wrote as code I wrote.
I set up a standing 4–5 person tooling group inside the test software team; over six and a half years it shipped 24 tools. Below is how the benefit distributes — click any bar to see what it did, who it served, and how much it improved.
Who got to decide “how a test runs” across eleven years. This trajectory is also why I left.
“The model we built ourselves in the second generation — write the test plan as a table, let the program be nothing but an executor — became the customer’s official standard two years later. That is both a validation of the design and exactly why I left: not because the work was hard, but because the part that required judgement had been taken away.” Why I left and what I am proudest of are two halves of the same story.
The same job — getting a unit through one full test run — is owned by different layers in each of the four generations. Deep blue is what we wrote; amber is the customer platform. You do not need to read the labels: the shifting ratio between the two colours is why I left.
The dependency chain in the last generation. A model project depends on the shared components for its model family; the family depends on the per-technology shared components; those depend on the common code every station uses. Each layer is a separately versioned, separately published package — this is not layering by convention, the chain is pinned in the build manifest.
All three were proven in real mass production, and I can go as deep as you like on the trade-offs and what each one cost.