The Skills We Stopped Teaching — and Now Pay For

 Today’s coffee: the last pot of Dunkin' Caramel Me Crazy.

Sweet, familiar, and oddly reflective. It’s the kind of coffee you don’t think much about—until it’s gone.

That feeling mirrors what’s happening in many IBM i shops today.

We didn’t lose critical skills overnight.
We let them fade.
And now we’re paying for them—in outages, delays, stress, and risk.

The Quiet Skill Fade No One Planned

No team ever said, “Let’s stop teaching fundamentals.”

Instead:

  • Teams shrank.
  • Systems grew.
  • Deadlines tightened.
  • Senior developers became permanent escalation points.
  • Junior developers learned just enough to ship the next ticket.

Over time, teaching became optional.
Delivery became mandatory.

The result is a generation of developers who can:

  • Modify code safely inside known paths.
  • Deliver features when patterns already exist.

But struggle when:

  • The system behaves unexpectedly.
  • The database pushes back.
  • A job runs differently at scale.
  • Production doesn’t match test.

This isn’t a talent problem.
It’s a knowledge transfer problem.

Skill #1: Understanding the Database as a Living System

We still teach SQL syntax well.

What we stopped teaching is how DB2 on IBM i behaves under real-world pressure.

That includes:

  • Why journaling isn’t optional in serious systems.
  • How commitment control protects integrity and performance.
  • How locking actually works—not how we wish it worked.
  • Why index design is a business decision, not just a technical one.
  • How query optimization can silently change after a schema update.

Without this knowledge:

  • Developers fear database changes.
  • Performance issues feel random.
  • Teams avoid refactoring data models—even when they should.

A modern developer needs more than SQL fluency.
They need database intuition.

Skill #2: Designing for Failure in Batch and Long-Running Work

IBM i still excels at what modern platforms struggle with:

But we stopped teaching how to design for interruption.

Things like:

  • Restartable batch jobs.
  • Checkpoint strategies.
  • Idempotent updates.
  • Safe reprocessing after partial failure.

So today, when a job fails:

  • Teams rerun everything.
  • Data gets duplicated.
  • Manual cleanup follows.
  • Confidence erodes.

Modernization isn’t about avoiding batch.
It’s about engineering batch that can survive reality.

Skill #3: Reading the System, Not Just the Source Code

Many developers can read RPG line by line.

Far fewer can answer:

  • Why this job runs under this subsystem.
  • Why this program behaves differently at night.
  • Why authority errors appear only in production.
  • Why a job log is warning you long before failure.

We stopped teaching:

  • How to diagnose using job logs.
  • How message queues affect flow.
  • How object ownership and adopted authority interact.
  • How environment configuration shapes runtime behavior.

When developers can’t read the system, everything feels mysterious.

And mystery breeds fear.

Skill #4: Recovery Is a Skill—Not a Panic Response

Modern teams focus on prevention, automation, and pipelines. That’s good.

But long-lived systems still experience:

We rarely teach:

  • How to recognize damaged objects.
  • When a rebuild is safer than a restore.
  • How to validate data integrity afterward.
  • How to fix problems without making them worse.

So recovery becomes:

  • Stressful.
  • Slow.
  • Dependent on “the one person who knows.”

A resilient system requires resilient operators, not just clean code.

Skill #5: Preserving the “Why” Behind the Code

Code without context is technical debt—no matter how clean it looks.

We stopped teaching:

  • How to document intent.
  • How to capture business rules clearly.
  • How to explain why this logic exists at all.

So over time:

  • Business meaning erodes.
  • Every change feels dangerous.
  • Developers avoid entire modules.

Modern tools can help generate documentation—but only if teams value the habit.

This Is a Leadership Issue, Not a Developer Failure

Developers didn’t choose to skip learning these skills.

They were never given:

  • Time to slow down.
  • Space to ask questions.
  • Mentors who weren’t overloaded.
  • Safety to admit uncertainty.

As leaders, we often reward:

  • Speed over understanding.
  • Output over resilience.
  • Heroics over sustainability.

When senior developers are always delivering, they’re not teaching.
When juniors are always rushing, they’re not learning.

That gap compounds quietly—until it’s expensive.

How Leaders Can Rebuild These Skills (Without Boiling the Ocean)

This doesn’t require a massive transformation program.

It requires intent and consistency.

  • Treat system understanding as part of real work.
  • Pair developers during incidents—not just feature builds.
  • Encourage “why” questions during reviews.
  • Capture recovery steps immediately after incidents.
  • Reward clarity, documentation, and shared knowledge.

Most importantly:

Make learning visible and valued.

If growth only happens after hours, it won’t last.

Final Sips

That last pot of Caramel Me Crazy didn’t taste worse because it was old.
It tasted familiar—because it mattered once, and still does.

The skills we stopped teaching didn’t disappear.
They became rare.

And rare skills are expensive—especially when your system depends on them.

Modern IBM i teams don’t need to abandon fundamentals.
They need to reclaim them, teach them, and pass them forward.

Brew the old wisdom with new tools.
That’s how systems—and teams—last.

 

Comments

Post a Comment