Labels

The Most Important Skill for an RPG Developer Isn’t RPG

First Sip

Today’s coffee is a familiar Dunkin’ medium roast. Dependable. No surprises.

That’s fitting, because the most important skill for an RPG developer is the same way. It doesn’t get conference talks. It doesn’t trend on LinkedIn. But without it, nothing else really works.

The most important skill for an RPG developer isn’t RPG.

It’s system thinking.

RPG Is the Entry Point, Not the Destination

RPG is how we express logic.
IBM i is where that logic lives.

Too many developers treat RPG like an isolated craft:

  • Write the program
  • Compile it
  • Test the happy path
  • Move on

That mindset works for small, disposable systems.

IBM i systems are neither small nor disposable.

An RPG program exists inside a living environment:

  • Jobs with lifecycles and priorities
  • Subsystems tuned for specific workloads
  • Data that has survived mergers, audits, and regulation
  • Schedulers, batch windows, and operational constraints

You don’t “just change code” on IBM i.
You change behavior inside a system that other systems trust.

What System Thinking Looks Like in Practice

System thinking shows up in how developers approach even small changes.

A developer without it asks:

  • “What do I need to code?”

A developer with it asks:

  • “What does this program participate in?”
  • “What assumptions does it make about data state?”
  • “Who else is relying on this behavior?”
  • “What time of day does this run?”
  • “What happens if it runs twice?”

These aren’t philosophical questions. They’re operational ones.

Most outages don’t come from bad syntax.
They come from correct code applied in the wrong context.

The Hidden Cost of Ignoring the System

IBM i is forgiving—sometimes too forgiving.

You can:

  • Lock files without realizing it
  • Add logic that slows a batch job by seconds… then minutes… then hours
  • Break downstream consumers silently
  • Introduce data drift that takes months to surface

The system won’t scream right away.
It will wait. Then it will collect interest.

By the time the problem shows up, the original change is forgotten—and now you’re debugging history.

System thinking short-circuits that pain.

The Real Difference Between Mid-Level and Senior RPG Developers

The gap isn’t syntax. It’s perspective.

Mid-level developers focus on:

  • Getting the code right
  • Solving the ticket
  • Closing the story

Senior developers focus on:

They know:

  • Which programs are load-bearing
  • Which files are effectively public APIs
  • Which jobs cannot fail
  • Which “small changes” are never small

That knowledge isn’t written down. It’s earned by paying attention to the system.

Why New Developers Feel Lost (And Why That’s Normal)

New IBM i developers often feel like they’re missing something—and they are.

What they’re missing isn’t skill. It’s visibility.

Most IBM i knowledge lives in:

  • Call chains
  • Job logs
  • Operational habits
  • “Don’t touch that” warnings

Without system thinking, onboarding turns into memorization.
With it, onboarding becomes exploration.

The fastest way to help new developers isn’t more RPG training—it’s helping them see the system.

Modern Tools Make This Skill More Important, Not Less

VS Code, Git, IBM BOB—these tools reduce friction.

That’s good.
It’s also dangerous.

When changes become easier:

  • More changes get made
  • Faster changes get promoted
  • Less time is spent reflecting

System thinking is what keeps velocity from becoming recklessness.

Tools don’t make good decisions.
Developers do.

How Developers Can Actively Build System Thinking

This isn’t abstract. It’s trainable.

Developers who grow fastest tend to:

  • Trace jobs end-to-end, not just programs
  • Read job logs after success, not just failure
  • Ask operators why things are done a certain way
  • Sit in incident reviews even when they didn’t cause the issue
  • Document why something exists, not just what it does

Curiosity is the multiplier.

What Managers and Leads Often Get Wrong

Many teams push developers to:

  • Close tickets faster
  • Learn syntax quicker
  • Adopt tools sooner

But they don’t reward:

  • Asking cautious questions
  • Slowing down risky changes
  • Saying “I don’t understand this system yet”

If you want senior developers, you must make system thinking visible, valued, and safe.

Speed without context is how outages are born.

Why This Skill Is the IBM i Community’s Quiet Advantage

IBM i has outlasted trends because its developers think in systems.

That mindset enables:

  • Decades-long data integrity
  • Continuous modernization without collapse
  • Stability that other platforms envy

RPG evolves.
Hardware evolves.
Tools evolve.

Systems endure because developers respect them.

Final Sip

RPG is important.
Tools matter.
Modernization matters.

But the most important skill an RPG developer can have is the ability to see the whole system—and act accordingly.

That skill builds trust.
That skill prevents incidents.
That skill turns developers into stewards.

And in the IBM i world, stewardship is everything.

 

Labels:

Comments

Post a Comment