The first thing you learn on a CNC machine is that the tool cannot go everywhere. There are hard stops, jigs, feed rates, and the grain of the material itself. The second thing you learn is that those limits are not in your way — they are the reason the finished part exists at all. The constraint is what makes the cut repeatable.
Software engineers tend to treat constraints as failures of imagination. I treat them as the medium. A fixed budget, a tight deadline, a narrow API, a language you cannot change — those are not obstacles in the path of the work. They are the path.
The tool shop rule
At Weng Seng we had a rule: if a part could only be made by one person on one machine with one specific jig, it was not really a part we knew how to make. It was a favor. The constraint we imposed on ourselves was that any production part had to be reproducible by any programmer on any compatible machine. That constraint is the entire reason a second machine was worth buying.
"Limits yield intensity."
— RICHARD SERRA
Software carries the same rule in different clothing. If a feature only works on one engineer's machine, on one environment, behind one feature flag only she remembers to toggle, it is not a feature. It is a favor. The constraint of "must run anywhere we run" is what makes the rest of the team able to build on top of it tomorrow.
The constraints you choose
The interesting constraints are not the ones the world imposes on you — those you just obey. The interesting ones are the ones you choose. No new dependency this quarter. No bespoke component when a shared one exists. No private API surface where a public one can carry the same weight. Every one of those is a small refusal that buys you something larger downstream.
Craft, in the end, is the discipline of choosing your boundaries and then treating them as real. The best engineers I know do not have more options than the rest of us. They have fewer, and they have decided their fewer on purpose.