Your true worth to your company and your true level of professionalism has nothing to do with what may seem so important today.

Sometimes it's easy to lose your perspective. Sometimes feeling good about your job isn't easy. Particularly in a world that likes to celebrate those who are on the bleeding edge.

We get excited about new things. Advanced techniques. Different languages. New tools. And sometimes we tend to focus all our attention on those cool, new things. It's as if those are the only things that matter and everything else is just filler. Unfortunately, those of us who write articles are some of the worst offenders here.

But that's not a healthy way to look at the IBM i world that most of us know. It's not an accurate picture of how things really work. Sometimes, the things that we pay the most attention to tend to be more like the icing than the cake.

What do I mean? Just that today we as professionals tend to be focused on one of two things.

Web-Oriented Modernization

The first is, of course, Web stuff.

Modernization is all the rage (as it should be), and interfacing the i database and logic with the Web is probably the biggest issue facing us today. As a result, it's not surprising that a great deal of coverage goes toward how to interface your current programs with the Web or else how to redo everything in a more Web-oriented language.

What makes this even worse is that there's no single path through this waste. Just the very number of languages and options that are available to the IBM i programmer is daunting, making the jump to the Web seem even larger than it really is.

The result is that it's easy to think that if you're not doing something related to Web programming then you're not doing something important. But that's not true at all. And, needless to say, if you're not doing Web programming and don't feel bad about it, please don't start. I don't want to screw up somebody who is doing OK just as they are. Lot of pressure on me with this article.

Technical Gurus 

The second is what I call "heavy metal" RPG—that is, doing things with either RPG or SQL that are very complex or involve characteristics of the languages that we generally don't use. In other words, really, really bizarre tough stuff. The kind of stuff where you have to get on the forums and really hash it out.

There's nothing wrong with that, of course. Someone's got to know how to do the hard stuff, but it can't become an end in itself. It would be silly to invent problems that can only be solved by very complex mechanisms without good reason. But just because you are not immersing yourself in ultra-technical stuff also doesn't mean that you are not playing a vital role.

Just Curious, But Is There a Point Here?

Of course there's a point. Man! What's being subtly ignored is the day-to-day type of work that most RPG programmers are embroiled in.

It's not Web-oriented. It doesn't require an advanced degree in technical complexity. It's just regular old, run-of-the-mill RPG/SQL/CL. And what does that get you? Well, it's that kind of work that keeps the companies we work for running. It's not sexy, but it's totally and completely necessary. And it, and the people who do it, get very little or no credit at all.

What Do These People Do?

So, if these folks aren't doing cutting-edge Web programming or super tech tricks, what the heck are they doing?

Well, first, they're keeping the historical record of their company's procedures. And to that some people will say, "Who cares?" But I, for one, do. Without a solid understanding of history, of what has worked or not worked, of what we have done that has had unpleasant consequences, we're going to continue to repeat the mistakes of the past.

Probably no one is more knowledgeable about the business processes of a company than the analysts in the IT group. For many companies that I have worked with, some of the most senior people (seniority-wise) in the company were in IT, and while there are advantages in being young and eager to prove that new technologies and techniques work, there's also an advantage in being seasoned and knowing what has and hasn't worked for a company in the past.

These analysts are doing the quiet detective work that's required to determine exactly what the users are thinking—that is, taking the business thoughts of the users and turning them into technical snippets that can become part of the system that keeps the company's heart beating.

In the end, what's really critical here isn't the technical language that's used to tell the computer what to do, but rather the ability to understand the business language of the users and convert that into what the machine can understand. Without a very thorough and comprehensive understanding of what the business needs and how it can be accomplished without damaging other areas, the technical aspect is severely hindered.

The second thing these people are doing is attempting to preserve database and program integrity for a system that's growing and changing.

It's relatively easy today to write good code if you're starting from scratch. You can determine exactly what type of program structure you want and what standards you're going to build into it. But it's much harder to keep things structured if you're in a maintenance or enhancement situation.

Almost without exception, there will be a quick and dirty way to accomplish what you want to do. And the pressure to do this, to expedite the project and get it done quickly regardless of the future consequences, may be almost overwhelming.

There's nothing more important to a company with a legacy business system (and I'm defining "legacy" to be any system more than two years old) than to keep the structure and integrity of that system clean and clear, because once it gets overlaid with a layer of complexity and confusion, it's very difficult to go back.

It's the people who make these maintenance changes in a civilized, standardized manner who are the heroes who really keep the system clean and maintainable into the future. They're the ones providing a true bang for the buck.

In the End

In the end, we would all like to be doing cutting-edge work. That's part of the definition of the word "professional." But not everyone gets a chance to do that. Many times, despite what we may want, we find ourselves in support roles. We're the ones who do the maintenance updates that occur every year. We're the ones who fix the bugs that users stumble over once a quarter. We're the ones who do the small, unremembered but required projects while others do the projects that everyone sees.

But just because our work isn't in the limelight doesn't mean that it's not critical to the success of the company. In the end, professionalism and vocational success are measured not by how many articles written about it or how many people are watching what you're doing, but by how many people depend on you to do it so that they can do their own jobs. And the real problem is that sometimes we forget that.

David Shirey is president of Shirey Consulting Services, providing technical and business consulting services for the IBM i world. Among the services provided are IBM i technical support, including application design and programming services, ERP installation and support, and EDI setup and maintenance. With experience in a wide range of industries (food and beverage to electronics to hard manufacturing to drugs--the legal kind--to medical devices to fulfillment houses) and a wide range of business sizes served (from very large, like Fresh Express, to much smaller, like Labconco), SCS has the knowledge and experience to assist with your technical or business issues. You may contact Dave by email at This email address is being protected from spambots. You need JavaScript enabled to view it. or by phone at (616) 304-2466.

---

MC Press books written by David Shirey available now on the MC Press Bookstore.

		21st Century RPG: /Free, ILE, and MVC Boost your productivity, modernize your applications, and upgrade your skills with these powerful coding methods. List Price $69.95 Now On Sale

Also Read

The Power of Writing Code in a Low-Code Solution

TechTip: Let’s Have a Date, Part 2

Going off the Rails