David Tatzel.

It started with screws. Whatever I could open as a kid — radios, the lawnmower, anything with a back panel — I'd take apart, lay the parts out on the floor, and work out how to fit it all back together. Some of it didn't fit on the way back. I learned from that too. The lesson stuck: every system, no matter how alien at first, is a stack of parts someone built and someone else can rebuild.

Forty-plus years on, I apply the same trick to everything. Figure out what the problem actually is. Break it into pieces small enough to be honestly faced. Solve each one. Reassemble. The medium changes — software, hardware, a microgrid, a bad week, a good team, a service panel, a transmission, a kid's hard question — but the discipline does not.

What changed is the price of that discipline. The distance between I could figure this out and I actually built it was once measured in years — or months, at the very least — the time it took to learn a craft well enough to execute in it. Agentic tools have closed most of that distance. What they haven't touched is the engineering discipline that separates work that holds up from work that only looks like it does: the decomposition is still mine, and so is the judgment. The barrier to starting fell; the premium on discipline rose. "Anyone can do anything" was always true given enough patience. Now it asks for far less — of everything but the discipline.

It's also what I look for in people — engineers and friends who may not yet know the answer but won't flinch from finding it. That stance has built my career, the team I lead at Savant, and the apps I ship in my off-hours. It also gets the dishwasher fixed.

The work itself almost always begins the same way: anything anyone touches has something in it that could be better — a workflow, a tool, a quiet friction nobody's bothered to name. The art is finding the real need under the surface ask. The science is everything after — framing it as a problem worth solving, choosing the materials, and building toward the best version of the thing rather than the first version that compiles. Most "feature requests" are the second sentence of a longer conversation; the first sentence is what to build.

Which leads to a rule I keep close: if a thing is worth doing, it's worth doing well. Make it feel like the perfect tool for the job — the one you reach for without thinking, the one that disappears into the work. The opposite — almost-right software, almost-right hardware — is its own kind of damage. It teaches users to expect less, and it lets the team's standard drift. I'd rather ship one thing that earns its place than five things that occupy it.