For most of my career, the worst case of a bug was a stack trace. A user saw the wrong number; a service returned a 500; an email went to the wrong address. Bad, sometimes embarrassing, almost always reversible.
Then I started writing software that drives 3D printers.
The new failure mode
A bug in slicer software is not a stack trace. It is a piece of plastic. It is six hours of machine time, a kilogram of filament, and a part that doesn't fit. The bug exists in the world.
You cannot git revert an extruded layer.
This changes how you write code. Defensive programming stops being a style and becomes a requirement. Every input is checked twice. Every transformation is reversible. The undo stack is sacred.
The slowness of physics
Software developers are used to feedback loops measured in milliseconds. Hardware feedback loops are measured in hours. You ship a fix, you start a print, you wait. If the fix was wrong, you find out tomorrow.
The discipline this imposes is — eventually — clarifying. You write more carefully because the cost of carelessness is higher. You read your own code as if a stranger wrote it, because by the time the print finishes, you might as well be a stranger.
Respect for the medium
What I did not expect was the respect that this kind of work induces. Bits are infinitely malleable; atoms are not. When your software shapes something physical, you cannot indulge the usual habits — moving fast, breaking things, fixing forward.
You learn, instead, to slow down. To consider. To ship less and verify more. The constraint is, in its way, a gift.