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.

The print bed taught me where that analogy holds and where it breaks. The break is the whole lesson.

Where the analogy holds: parametric design is codegen

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.

Where it breaks: the build runs whether you were right or not

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. And here’s the part that reorganized how I think: the printer runs your model whether it was right or not. It doesn’t validate. It doesn’t warn. It faithfully spends four hours and a spool of filament turning your mistake into a solid object you now have to hold, evaluate, and throw away. The .rej file in my folder isn’t a compile error I dismissed in a second. It’s a decision I could only reach after watching a wrong version become physically real.

The loop length is the thing

This is really a lesson about feedback loops, and how much the length of the loop shapes the discipline you need.

In software I’d gotten used to a loop so tight that being sloppy is nearly free — I could offload judgment to the compiler and the test suite and just iterate my way to correct. 3D printing stretches that loop to hours and staples a material cost to it, and suddenly the discipline that software lets you skip becomes mandatory. Measure twice. Check the tolerances against the actual thing the part bolts to. Run the fit in your head before you commit the bed. The printer will not catch your mistake for you, so you have to catch it yourself, up front, the way people had to before the loop got instant.

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 keep doing it

Touching hardware recalibrates you, and that’s the real reason it’s worth the filament. When the build is instant and free, you get sloppy in ways you stop being able to see — you let the loop do your thinking, and you forget that the cost of a wrong assumption didn’t disappear, it just got hidden behind a fast redo. Hardware puts the cost back where you can feel it, in hours and grams, and that feeling carries back to the keyboard, where the cost of a careless assumption was always there too — just quiet.

I still name my print files like commits, and I still think parametric modeling is codegen. But .rej is the file that taught me the most, because in software I’d have deleted that mistake and forgotten it inside a second. Here I had to hold the failed version in my hand — four hours and a spool of filament heavier — before I could let it go. You can’t hotfix atoms. Which turns out to be a good thing to be reminded of, occasionally, by a machine that does not care in the slightest whether you were right.