The Maker Mindset: What the Workshop Teaches About Software

I build physical things, woodworking, CNC, 3D printing, electronics, and I build software, and the two practices have been quietly correcting each other for years. This is about what the workshop teaches that the editor can’t, because the lessons only exist where mistakes cost material.

The first thing wood teaches is that reality doesn’t accept refactors. Cut a tenon a sixteenth short and there’s no undo, no quick patch before anyone notices. You either design a recovery the piece can absorb or you start the component over, and both options cost real hours and real stock. That changes how you plan, permanently.

In software, the cheapness of iteration has bred a habit of thinking with the keyboard: try it, run it, tweak it. Mostly that’s a gift, and I use it all day. But some decisions in software are load-bearing the way a mortise is. Data models. Public APIs. The boundaries between components. Get those wrong and you’re not tweaking, you’re rebuilding with everything already glued up. The workshop habit of measuring twice transfers exactly to them, and the skill underneath is the same in both shops: knowing which of your cuts are reversible. Physical making drills that distinction until it’s reflex. Software, left to itself, erodes it.

The second lesson is that materials push back. Wood has grain, metal has temper, and the design that ignores the material fails no matter how clever it is. Software pretends to be infinitely plastic, and it lies. Every codebase has grain, directions it wants to bend and directions where it splinters, and the developers who fight it produce the same tearout as a router run the wrong way. I’d never have put it that way before I’d felt actual tearout, which is the point: the workshop gives you the physical referent for a thing you were half-noticing on screen.

Then there’s finishing. A piece of furniture is done in a way software never is. It sits in a room, it holds weight, nobody ships it an update. I underestimated how much that completeness matters to me until I had it to compare against. Software’s infinite revisability is its power and also a low-grade ache. Nothing is ever finished, and the workshop is where I go to remember what finished feels like.

So the claim I’ll hang this on: every software engineer should build something physical. Not for the metaphors, for the calibration. Digital work misprices mistakes, hides materials, and never ends. An afternoon in the shop resets all three gauges.

The honest counterweight, so this doesn’t drift into craft romanticism: iteration speed is the digital world’s real advantage and I wouldn’t trade it. Being able to try five approaches in an hour is worth more than all the woodshop wisdom in the world for most problems. The point isn’t that slow is virtuous. It’s that speed without the memory of cost breeds carelessness, and the shop is where the memory gets refreshed. I don’t go out there to work slower. I go out there to remember why, back at the desk, I sometimes should.