DEV Community: Ken Morgan

My First Stack Wasn’t Even a Stack

Ken Morgan — Sat, 11 Jul 2026 20:50:24 +0000

My first stack wasn’t even a stack.

It wasn’t even mine.

It belonged to an elementary school.

Somewhere around 1979 or 1980, I was in the SPARK program (Seeking Purposeful, Analytic, Realistic Knowledge) for gifted students. That’s where I first encountered what many older developers will immediately recognize.

A TRS-80.

Programming in BASIC.

No hard drive.

No floppy drive.

A cassette tape.

Yes, tape.

I wanted to learn everything I could about it, but computer time was limited, and there was no chance we could afford a computer at home.

Years later, I had another brief encounter with an updated TRS-80 in high school. Computer Literacy had finally made it into the curriculum — but the class was split with Business Law, so keyboard time was still measured in minutes instead of hours.

Then life happened.

I didn’t have regular access to a personal computer until 1996, after my wife and I got together.

My First Paid Development Job

By 2002, I’d learned enough HTML, CSS, and JavaScript — the “core three” of the web at the time — to build a small website for my wife’s uncle.

It was my first (and only) paid development job.

The flat-rate payment was nearly double what I normally made in a week, and I happened to be unemployed at the time.

Of course I accepted.

Then reality arrived.

I spent two or three days fighting WYSIWYG editors and Microsoft Word, trying to stop them from “helping” me by rewriting perfectly good HTML.

Eventually I gave up.

I opened Notepad.

Everything suddenly became easier.

The website finally worked.

The Internet Archive still has a copy:

https://web.archive.org/web/20021210054808/http://ticd.info/

Looking back now, it’s incredibly simple.

Back then, though, it represented something important.

Someone trusted me enough to pay me to build software.

The Hard Lesson

That project stressed me out more than I can adequately describe.

People often talk about imposter syndrome.

This wasn’t that.

I simply wasn’t ready.

If a small website required several days of wrestling with my tools before I could even begin solving the real problem, there was no way I was prepared to build software professionally.

That realization stayed with me.

I didn’t have a computer science degree.

There were no YouTube tutorials.

No AI assistants.

No affordable online bootcamps.

Mostly there were books I could afford, documentation I could find, and viewing the source code of websites I admired.

Twenty Years of Learning

In 2017, I completed Rob Percival’s Web Developer Bootcamp on Udemy.

I earned several SoloLearn certificates afterward.

They all taught me something.

None of them made me feel job-ready.

Then, during a layoff in 2024, I attacked learning with everything I had.

I made it through the first eight sections of Angela Yu’s Full Stack Web Development Bootcamp and completed the first three courses in IBM’s Full Stack JavaScript Developer Professional Certificate.

For twelve days, learning became my full-time job.

Then I was called back to work.

The momentum disappeared.

My Coursera funding ended before I could return.

Fortunately, I’d already purchased Angela Yu’s course.

So now I’m starting again.

But this time with a different philosophy.

Build. Audit. Fix. Ship.

I’m no longer trying to finish courses.

I’m trying to build software.

Learn enough to create something useful.

Build a real project — not another tutorial clone.

Test it.

If it’s broken, audit it.

Fix it.

Test it again.

Document everything.

Ship it.

Then repeat.

Every project should leave my local machine only after I’ve made every reasonable effort to ensure it works.

Not because perfection exists.

Because professionalism does.

Why It Matters

I’m trying to transition into software development after spending more than two decades working as a boilermaker.

When that transition finally happens, there won’t be a manager standing between me and the quality of my work.

There won’t be a committee.

There won’t be a supervisor.

There will only be clients.

As a solo developer, there’s nowhere to hide.

Either the software works, or it doesn’t.

Either the client trusts you enough to come back, or they don’t.

Without clients, software development is just a hobby.

And hobbies don’t pay the car note.

That’s why this time feels different.

I’m not just learning to code anymore.

I’m learning to deliver.

My first stack wasn’t even a stack. It was a TRS-80 with a cassette drive. Forty-six years later, I’m still learning—but now I’m learning with one goal in mind: to deliver software people can trust.

What a Refinery Taught Me About CI Pipelines

Ken Morgan — Sat, 11 Jul 2026 15:25:30 +0000

I’m currently relearning the Core Three — HTML, CSS, and JavaScript — as I work toward becoming a full-stack JavaScript developer.

Before I came back to learning software, I spent 22 years working industrial turnarounds.

One lesson from that world has followed me into software engineering:

Never trust a single point of failure.

In industrial maintenance, there’s a safety practice called double block-and-bleed.

Instead of trusting one isolation valve, you use two independent valves with a bleed point between them. If one valve leaks, you know immediately. The entire system assumes individual components can fail.

Safety doesn’t come from perfect parts.

It comes from independent layers of protection.

That idea completely changed how I think about CI pipelines.

When I first started relearning web development, my mindset was simple:

Run Lighthouse.

Everything green?

Great.

100 across the board locally?

Even better.

Ship it.

Different results after deployment?

Uh-oh.

Now I see Lighthouse as one checkpoint — not the finish line.

A fast website can still have accessibility issues.

An accessible site can still have broken metadata.

Good SEO won’t catch rendering bugs.

Passing unit tests won’t tell you if the generated HTML is malformed.

Every tool has blind spots.

No single tool should get the final vote.

So instead of asking:

“Did my tests pass?”

I ask:

“What kinds of failures could still slip through?”

That question naturally leads to layered validation.

Formatting
Linting
Type checking
Accessibility checks
Performance audits
HTML validation
SEO analysis
Manual review

None of these tools is perfect.

Together, they’re much stronger than any one of them alone.

The more I learn about software, the more I find myself applying lessons from heavy industry.

Different environment.

Different risks.

The same engineering mindset.

Assume components will fail.

Design systems that fail safely.

That’s becoming the philosophy behind every test matrix and CI pipeline I’m designing.

What’s one engineering principle from outside software that’s changed the way you write code?

Night of the Living Bugs

Ken Morgan — Sun, 05 Jul 2026 11:23:19 +0000

from https://www.kmwebdev.me/blog/night-of-the-living-bugs

At 4 AM, the CI pipeline wasn’t broken. It was confused. What I thought was a simple automated check had turned into a chain of small misunderstandings across multiple systems.

Everything was still “working,” but the results no longer made sense. That gap between execution and understanding is where everything started to fail.

The system I thought I was building

The goal was simple: run automated checks on a website, measure performance, and return a clear pass or fail result.

Check if the site loads correctly
Measure performance metrics
Validate stability
Return a single decision

On paper, it was deterministic. In reality, it depended on many components agreeing on how data should move between them.

The first sign of failure

The system didn’t crash. It returned incomplete results. Some values were missing. Others were undefined. The final output simply said: FAILED.

But it couldn’t clearly explain why.

It wasn’t broken. It was confused.

Where things started drifting

Each part of the system assumed the previous part had already done the necessary transformation. But those assumptions were never explicitly defined.

Small mismatches started accumulating:

One step expected structured data, another sent raw output
Some values were optional but treated as required
Undefined values propagated silently through the pipeline

Nothing failed loudly. Everything failed quietly while still running.

The environment failure

Once internal issues were reduced, a different problem appeared: the system tried to use a tool that wasn’t installed.

No crash. Just a message:

“I can’t find what I was told to use.”

At that point, it stopped being a logic problem and became a setup problem.

The turning point

The breakthrough wasn’t a fix. It was separation.

One stable version for known behavior
One experimental version for testing changes

Before this, everything was mixed together. Every change had unpredictable effects. After separation, the system finally became observable again.

What this actually was

This wasn’t a single bug. It was multiple small gaps aligning at once.

Data contract mismatches between layers
Missing environment dependencies
Unstable state across versions
Over-composition before stabilization

Most systems don’t fail dramatically. They fail quietly while still running.

Closing thought

I thought I was debugging a CI pipeline. But I was really debugging assumptions: the invisible agreements between parts of a system.

The bugs weren’t random. They were the system failing to agree with itself.

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.