There's an unspoken fork in a lot of engineering careers. You go toward the floor — toolpaths, fixturing, metrology, the physical reality of making parts — or you go toward the software — code, data, systems. Most people pick a side and get good at it.
I never managed to pick. On one side I work in Mastercam, Rhino + Grasshopper, and ANCA iGrind, designing and grinding cutting tools. On the other I write Python automations, web apps, and ERP integrations. And the longer I do both, the more I'm convinced the best problems live in the seam between them.
Why the seam is where the value is
Look at where the real wins came from:
- The 45→20 minute toolpath came from treating a manufacturing motion as a geometry problem I could model.
- The ERP ↔ cell bridge came from knowing both what the production process needed and how to talk to the APIs.
- Machining printed parts needed metrology *and* parametric geometry *and* CAM, in one coordinate system.
None of those is a pure software problem or a pure manufacturing problem. They're translation problems — and you can only solve a translation problem if you're fluent on both sides.
What "Applications Engineer" means to me
It's the person who can stand at the machine and read the chatter, then sit down and write the tool that fixes it. The title is just shorthand for refusing to choose between the floor and the codebase.
The cost and the payoff
The honest downside: you're never the single deepest specialist in the room on either axis. The upside is that you're often the only person who can see the *whole* problem — and a lot of expensive problems are expensive precisely because they fall between two specialties and nobody owns the gap.
I bridge the shop floor and the codebase. The interesting failures almost always live in the gap between them.
If you're early in your career and you feel pulled in both directions — toward the hands-on and the abstract — you don't necessarily have to resolve it. There's a real role in being the person who connects the two.
