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

Ken Morgan — Sat, 04 Jul 2026 15:39:15 +0000

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

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.

⸻

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.

DEV Community: Ken Morgan

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