I Spent 20+ Years in Industrial Maintenance. Now I’m Learning to Build Software.

I spent over 20 years working in industrial maintenance as a boilermaker.
Most of that time was in refinery shutdowns and turnarounds—high-pressure environments where systems either hold or fail.

There is no “mostly working” in that world.

That experience has shaped how I approach software development.

⸻

I’m not just “learning to code.” I’m building systems.

I’m currently working on transitioning into web development, but I’m not approaching it as a tutorial exercise

I’m building real projects from day one—and documenting the process as I go.

Not theory. Not exercises. Actual systems that are meant to run.

⸻

What I’m building right now

1. A portfolio site that behaves like a system (kmwebdev.me)

This isn’t a “personal website” in the usual sense.

It’s a live system under controlled change.

I treat it like industrial maintenance work:

• versioned updates instead of redesigns
• small, controlled changes only
• tracking what changed and why
• stability over aesthetics

Nothing gets changed without intent.

⸻

1. A production-focused email framework

Alongside the portfolio work, I’m building a separate system for HTML email development.

Email is one of the most constrained environments in web development. Rendering is inconsistent, standards are partial, and modern CSS support is unreliable across many clients.

So instead of fighting those constraints, I’m building a framework specifically designed around them.

The focus is simple:

predictable rendering in real-world email clients

It’s still early, but it’s being developed with production use in mind—not experimentation.

⸻

The way I work hasn’t changed—only the tools have

In industrial maintenance, you learn a few hard rules:

• don’t assume—verify
• don’t scale chaos
• don’t change more than you can test
• document everything that matters

So I carry that directly into development:

• versioned releases (v1.0, v1.3.6, etc.)
• controlled incremental changes
• explicit documentation of limitations
• real-world testing across environments
• stability over experimentation

If it wouldn’t pass a shutdown QA mindset, it doesn’t ship.

⸻

Why I’m sharing this

I’m not writing this as a tech influencer or tutorial creator.

I’m here mid-transition; moving from physical industrial work into software.

This is what the transition actually looks like in real time.

• learning
• building
• breaking things
• fixing them
• and shipping anyway

No shortcuts. No fantasy timeline.

Just work.

⸻

Where this is going

The goal is to build toward something sustainable:

• remote software work
• productized tools
• income that doesn’t depend on physical strain

But right now, it’s just the foundation phase.

One system at a time.

⸻

If you’re also building or transitioning from a completely different field into tech, you’re not starting behind.

You’re just starting with different constraints.

If you want to see where that shows up in practice, the portfolio’s at https://www.kmwebdev.me.