Software engineers figured this out twenty years ago: claims are cheap, so show the work. Manufacturing is only now catching up, which is exactly why it works so well — when every resume in the pile says "proficient in Python, experienced with CNC programming," the one with a link where the hiring manager can see the cycle time drop gets the phone call. This site is my own attempt at the genre, so consider this post both advice and a worked example. If you're still deciding whether the code side is worth investing in at all, I've made that case separately — this post assumes you have work worth showing and don't know how to show it.
What a portfolio is for (it's not a gallery)
A hiring manager spends about ninety seconds deciding whether you're worth a conversation. The portfolio's only job is to make those seconds land on evidence: this person meets real constraints, measures results, and can explain their work. Three to five projects told well beat twenty screenshots every time.
The case-study format that works
- 1The problem, in shop terms. "Order entry into the robot cell took 20 minutes of retyping per job and produced transcription errors." One sentence; a hiring manager should recognize the pain instantly.
- 2The constraint that made it interesting. Locked-down IT, no budget, a 30-year-old control, a certification requirement. Constraints are where engineering judgment shows — and judgment is what's actually being hired.
- 3What you built, briefly. Tools and architecture in a paragraph, not a spec sheet.
- 4The number. 45 minutes to 20. Four setups to one. Zero transcription errors since March. If you didn't measure it, the story is missing its ending — go measure the next one.
- 5What you'd do differently. One honest sentence. Nothing signals "safe to hire" like calibrated self-criticism.
"But my work is proprietary"
The most common objection, and the most solvable. You don't need the employer's part drawings — rebuild the pattern on toy data: the ERP integration becomes a demo against a fake orders CSV; the G-code generator ships with a made-up part family. Skills transfer, specifics stay behind. When even that's too close, write the case study with the numbers genericized — "a 40% cycle-time reduction on an aerospace component" breaks no NDA.
Show the code, even the ugly code
A GitHub profile with three real repositories beats a skills list every time. For each: a README that says what problem it solves in manufacturing terms, one screenshot or GIF of it working, and honest scope ("built for our shop's workflow; fork accordingly"). Don't polish for weeks first — working-but-unglamorous is credible precisely because that's what real internal tooling looks like. An engineer who codes is still an engineer first; the code is evidence of leverage, not a bid to join a dev team.
Skip these
- Tutorial projects. The Udemy to-do app tells a hiring manager one thing: you finished a course. One real shop problem outweighs ten of these.
- Skill-percentage bars. "Python: 85%" is meaningless to everyone including you.
- Walls of unexplained CAD renders. Pretty geometry without problem/constraint/result is a screensaver.
- Listing every tool you've ever opened. Depth on five beats logos of fifty.
Where does it live? Anywhere the link works — GitHub Pages and a README-driven profile are plenty. A personal site adds polish (and, eventually, a blog that does your networking for you), but content beats platform: the constraint-and-number stories are the portfolio; everything else is packaging. Build the stories first. If you've built yours and want a second pair of eyes, I read these gladly.
