Seven months ago my job was building things you can stand on. Now I build software. The thing nobody warned me about is how much of the trade carried straight over — not the skills, the ethics. The unwritten rules about how you treat a job site turn out to be better engineering principles than anything in a tutorial, and most developers picked up code without ever picking those up.

Here's what I mean.

You leave the site cleaner than you found it

On a job site this isn't a nicety, it's a rule. You don't leave your offcuts in the next guy's way. You don't bury a problem behind drywall for the homeowner to find in two years. You sweep before you leave, because the next trade through has to work in the space you left, and your name is on what they find.

Code is the same and almost nobody treats it that way. Every file I touch, I own — not just my new lines, the whole file, for as long as it lives. So I sweep my diff before I commit: no dead variables left lying around, no console.log offcuts, no half-finished thing buried where the next person trips on it. The next developer through that file is a real person working in the space I left, even if that person is me in three months. You leave it better than you found it. That's not code style. That's job-site manners.

You don't hide bad work behind the finish

The most dangerous guy on a site is the one who's good enough to make bad work look finished. Caulk over a gap instead of fixing the framing. Paint over the rot. It looks done. It passes a glance. It fails the first hard winter, and by then he's three jobs away and it's somebody else's emergency.

Software has the exact same temptation and it's even easier to give in to, because the rot is invisible. The feature works in the demo. The green checkmark is on. But the demo passing isn't the same as the thing being sound — I've shipped code that looked finished and was caulk over a gap, and I've learned to distrust the glance. Did I check the edge cases or just the happy path? Did I verify it, or did I read it and assume? On a job site you find out you cut a corner when something falls. In software you find out at 2 a.m. when it's in production. Same lesson, worse hours.

You price the work fair, and you price loyalty even fairer

In the trade you learn fast that the person who took a chance on you when you were nobody gets a different number than the stranger who found you on Google. Not because you're soft — because that's how you keep the people who built you. You make your money on strangers at a fair rate. You don't squeeze the ones who opened the door.

I run my business on that and I built FairTradeWorker around it, because the construction marketplace forgot it. The whole industry runs on squeezing whoever has the least leverage — the homeowner who doesn't know the going rate, the sub who needs the work this week. Fair pricing isn't a marketing line for me. It's the one rule from the trade I refuse to leave behind, and it's load-bearing in everything I ship.

The part they get backwards

People assume going from construction to software meant leaving the trade behind and becoming a "real" engineer. It's the other way around. The trade gave me the standards. The hard part of engineering was never the syntax — you can learn syntax in a weekend, I did. The hard part is giving a damn about work nobody will see: the framing behind the drywall, the function nobody reads, the edge case that'll never come up until it does.

That's not something a bootcamp teaches. It's something a job site beats into you. Turns out it's the most transferable skill I own.