From Wrench to Keyboard: What Three Years in Sheet Metal Taught Me About Software Engineering

People at meetups sometimes do a small double-take when I tell them what I did before software. Sheet metal worker. That's the closest English term for it. In Switzerland the trade is called Spengler, and it covers roofs, gutters, façades, ventilation ducts, plumbing. Four years of apprenticeship, then more time on the tools, from 2019 into 2024. Now I sit at a desk and my biggest physical risk is bad posture.

The obvious question is why I switched. The more interesting one, at least to me, is what I brought with me. Because the answer is: more than I expected.

Why I left

I didn't leave because I hated it. There's something satisfying about building something with your hands, standing back at the end of a week and knowing which folds are yours. The craft was never the problem.

The problem was the trajectory. The work wrecks your body. Knees, back, shoulders, daily, in every weather. I was in my early twenties hearing guys in their forties compare which joints had given up. I did the math on twenty more years and didn't like the answer.

The other reason was that most problems on a construction site are already solved. The details are standardized, the materials are specified, the techniques have been refined for centuries. That's great for quality. It's boring for someone who wants to keep learning things that are fundamentally new. I wanted work where the ceiling keeps moving faster than I can climb.

Software had been a background hobby for years. Scripts, Linux, breaking my own machines and fixing them. At some point I decided to go professional properly, through the Swiss system. Did the Informatiker EFZ at Computerschule Bern AG, finished July 2025. What surprised me wasn't how much I had to learn. It was how much of the old job kept being useful.

Precision is a method, not a personality trait

In the metal shop, a tolerance is a tolerance. If your sheet is two millimeters off at the edge, the error compounds across every fold, and by the fourth seam nothing fits and you're cutting a new piece. "It doesn't compile" doesn't work as an excuse on a roof. You learn fast and physically to measure twice, mark accurately, and check before the material punishes you.

That transferred to code. Not because I'm naturally careful. I'm not, particularly. But because precision is something you build into the process. In the trade it was the square, the scribe, the test-fit. In software it's types, tests, linters, actually reading the diff before you commit. The tool changed. The habit didn't.

The flip side: a good sheet metal worker doesn't polish the inside of a downpipe nobody sees. In code, that instinct keeps you from gold-plating. Rough prototype first, precise at the interfaces. That's how you build a ventilation system too. Get the airflow right, then make the visible parts look good.

Planning on paper is cheaper than improvising on site

Every construction job starts with a plan, and the plan is always wrong in some detail. The wall that should be straight isn't. The dimension in the drawing doesn't match what's actually there. The delivery is late. Nobody with experience treats this as planning failure. It's the reason you plan: so when reality deviates, you know immediately what changed and what it affects downstream.

Software has the same physics. I watch developers treat a plan as a contract and then panic or silently flail when it breaks. On site you learn a healthier relationship. The plan is your measuring stick against reality. Deviation is information, not catastrophe.

There's a subtler habit too. Sequencing. You can't solder a fitting after you've enclosed it in a wall. You can't install flashing after the roof is closed. Order of operations is physical and irreversible, so you think in dependencies constantly. Turns out dependency graphs are dependency graphs whether the nodes are build tasks or plumbing connections. When I learned how CI pipelines worked, the mental model was already there. I'd just never called it a DAG.

Physical systems thinking is systems thinking

A plumbing system and a distributed system are more alike than either profession wants to admit. Both have flow, capacity constraints, backpressure, cascading failures, and, my favorite, failures that are silent until they aren't.

Water doesn't care about your intentions. It follows physics. A venting problem three floors up shows up as a gurgling drain at the bottom, and if you only look where the symptom is, you'll never find the cause. Debugging taught me I already knew this: never trust the symptom's location, trace the path of the thing that flows, water, air, data, requests, and find where the actual state diverges from what you expected.

Physical systems also give you a tactile respect for failure. A leaking pipe is a leaky abstraction you can touch. Every barrier fails eventually. Water finds every seam you rushed. "It held during testing" means very little against a winter. Software people rediscover this as "testing in production" and "chaos engineering." Sheet metal apprentices rediscover it at 7 a.m. on their first frozen burst pipe. The career-change route is cheaper.

One more: maintenance. Buildings outlast anyone's memory of how they were built. The person who services your installation in twenty years never met you and can't ask questions. You either leave behind something understandable, or you leave a trap. When I write code now, I think about that future stranger more than I think about the reviewer.

What didn't transfer

Honesty time. Physical intuition can mislead you in software. Resources in code aren't consumed the way material is. Scale breaks physical metaphors. A system handling a million requests doesn't behave like a pipe with a million liters. The social structure is different too. A construction site has a clearer hierarchy and faster feedback about who's competent than any engineering org chart I've seen.

The biggest adjustment was feedback latency going the other way. On a roof, you know within a day if your work holds. Software can fail six months later in somebody else's workflow because of an edge case you never imagined. Learning to defend against invisible, delayed failure, observability, tests, design reviews, was genuinely new. Nothing in a hands-on trade prepares you for that.

So

I sometimes see career changers apologize for their past, frame the old job as wasted years. I can't do that. The trade gave me precision as a habit, planning as a reflex, and a gut-level understanding that systems fail where they're weak, not where you're looking. Three years of bending metal made me a better engineer than three more years of theory would have.

If you're coming into software from something "non-technical": you're carrying more than you think. The tools are new. The thinking usually isn't.