You Can't Hotfix Atoms
I have a folder of 3D models where the files are named like a codebase: v3, v4, v6 — v5 didn’t make it — and one file literally named .rej, for rejected. I’d designed a small family of parts: an M.2 SSD extender re-derived across five standard sizes, a case for a single-board computer, even a set of earrings. And I versioned them exactly the way I version software, with the same instinct and the same vocabulary.
Some parts of that analogy held. The cost and timing of a bad build did not.
Parametric design behaved like code generation
I drew the M.2 extender once, parametrically, and re-emitted it at five different form-factor sizes by changing a single variable. That’s codegen. One template, many outputs, each derived from the same source by flipping a parameter — exactly what a code generator does, except the output is a physical object instead of a file.
And the versioning was real versioning. Iterate the model, export it, name it the next version, keep the ones that didn’t work. My design folder reads like a commit history because I treated it like one. Up to here, “designing hardware is just like software” is a completely fair thing to say.
A four-hour build made mistakes expensive
In software the build is instant and free, which makes being wrong cheap. You compile, see the error, fix it, rebuild — all in seconds. The tight loop does a lot of your thinking for you; carelessness barely costs anything because the feedback is immediate and the redo is free.
A 3D print is a four-hour build with a material cost. The printer does not validate the model or warn about a bad fit. It spends the same time and filament producing a mistake as it does producing a useful part. The .rej file in my folder records a decision I could make only after the wrong version became physical.
A longer feedback loop changed how I worked
In software I had grown used to a tight loop: compile, test, correct, repeat. A printer stretches that loop to hours and attaches a material cost. I started measuring twice, checking tolerances against the actual hardware, and reviewing the fit before committing the bed because the machine could not cheaply expose those mistakes for me.
The extender had to seat on real boards, so I designed it against the actual models of the hardware — and a part is only as correct as your assumptions about the thing it mates with. A fraction of a millimeter off and it doesn’t fit. Software rarely punishes an off-by-a-little; a physical fit does, immediately and without appeal.
Why I still print parts
Working with hardware makes the cost of a wrong assumption visible in hours and grams. That has made me more deliberate back at the keyboard too, even when a compiler can expose the mistake within seconds.
I still name print files like commits, and parametric modelling still feels like code generation. The .rej version remains because I had to hold that failure in my hand before changing the design. You can patch the model, but you cannot hotfix the four hours of plastic already on the desk.