Clif Notes: New Blood — Part 1

Ah, another year behind us. A new year ahead of us. Time to see what lessons we may have learned and look to the year ahead; at how we might apply those lessons. What things can we do differently? And what things can we avoid doing at all.

I'm not going to propose a set of resolutions we all agree to try to implement - and fail the second week. No manifesto for us all to argue about, water down, and then, seething with dissatisfaction, sign and then ignore. I just want to talk a bit about some of my observations, interpretations, and suggestions of actions we consider.

Us. We.

Not Them. They.

Us. The community of MultiValue Developers. Some of us are lower level programmers. Some are analyst programmers. Some are managers of MultiValue development groups.

It appears to me that whenever the discussion turns to "What can be done to promote MultiValue in the marketplace?" invariably people start chiming in with, "They (the database Vendors) need to put tons of money into advertising." "They need to be more aggressive about convincing everyone else of the superiority of the MultiValue Model." All the way from "They need to do more marketing" to really off-the-wall demands like, "They need to spend thousands of development dollars reinventing .NET / Java / Eclipse / whatever in the MultiValue environment so we don't have to learn anything new and can do *everything* from inside our isolated environment.

It always seems to be about Them and what They need to do. Well, We don't have any control - and very little influence, frankly - over Them and what They do. So let's drop that discussion this year, could we? Let's concentrate on what We can do to promote MultiValue and help it not only survive but thrive.

First, let's talk about the issue of the aging of the MultiValue community. This seems to be "common knowledge," though I've never seen any data supporting that conclusion. Being one of the "old-timers," I can understand how a lot of people have come to that impression. If you attend the International Spectrum Conference regularly, some people will focus on the fact they are seeing some of the same faces over and over. They don't even notice the new attendees (or have discussions with them). If the same-old same-old is what you are expecting to see, that's pretty much just what you will see. It's part of how our brains filter things for our attention. Go get a scuba diving certification. You will be amazed at how many cars and trucks on the road suddenly have "dive flag" decals on them.

So while I will accept the premise that we are losing experienced MultiValue developers to retirement, I'm not sure we're all getting ready to leave the community in a mass exodus.

Still, I think it is imperative that if we are to survive as a community, we need new blood — not only to increase our numbers but to bring in new ideas, new knowledge, and avoid stagnation. Stagnation will, I think, guarantee that MultiValue fades away.

So we need new, younger, dedicated developers. Agreed. Now, how do we get them? Organizations like International Spectrum serve a role. If you join those of us who are going to attend the Conference this year, I think you will see some interesting sessions targeted directly at new developers and non-MultiValue developers to introduce and educate them on the key concepts, abilities, and use of the MultiValue platforms. Of course, you could help in that effort by volunteering to give a presentation, conduct a technical session, or contribute an article or two to Spectrum Magazine.

But I don't think that simply supporting an organization's efforts is enough. It's going to take individual efforts to keep this thing going. What can you, as individual, do to attract new blood?

Participate in Internet discussions. Social media. Comment on technical blogs. Discussion groups on platforms like LinkedIn, Google, and the like. Twitter, Facebook, and others.

When we talk of "new blood" we are usually talking about developers who fall into the vague generational classification of "Millennials." So if you want to attract Millennials, you need to hang out where the Millennials hang out. That means the Internet.

But please be careful what you say and how you say it!

As I followed discussions on some of the groups last year, I was dismayed at some of the comments I saw. Comments that stated things that were obviously false, such as "There hasn't been any changes to MultiValue in 20 years," to raging against having to learn anything outside of MultiValue. Some of the threads were very negative, critical, and belittling of the MultiValue platform and vendors.

I cringe when I think of what the Millennials in IT will think of MultiValue when they see that. These forums are, of course, wide open for the world to read.

Imagine for the moment you were 23 years old, bright, enthusiastic, technically savvy with a broad skill set — the very type of new blood we are looking for. You have two job offers. One is with a company using a well-known database, .NET, Ajax, etc. The other is for a company using something called MultiValue (or the old term PICK). Not having heard of the latter, you head out to the Internet and start browsing around. You find message threads full of longtime MultiValue developers "discussing" the horrid state of affairs — "Nothing new in 20 years," "The vendors don't care and aren't enhancing the product," and arguing about being forced to use non-MV products like .NET / Java / Python because of the deficiencies of the MultiValue platform. And the list of negatives go on.

Which job are you going to accept? You think you are going to be attracted to what appears to be a dead-end job using a dead-end product while your hard-earned skill-set atrophies, leaving you behind all your IT colleagues? Not likely.

I am not suggesting we censor the MultiValue discussion lists! Even if it were possible. Forbid any negative postings about vendors? Wash your mouth out with libertarian soap. There are, however, two things we as individual developers can do to help the situation.

First, think before you post. Simply ask yourself if what you are going to say is factual, stated fairly, and does it really need to be said. How would a prospective young developer react to MultiValue if they read this?

Second, if you are one of the modern MultiValue developers using modern tools like .NET, PHP, Python, JavaScript, etc., PLEASE get more active in the online discussions! Lead by example. Talk about what you are doing, how your shop uses a certain tool to build applications. How a certain coding technique has helped your shop speed up development of new applications and how you adapted that technique to MultiValue.

There are always going to be negative threads in a discussion group. But as long as they don't become the majority of the group's content, they won't hurt much. The new crop of IT professionals are as good at spotting a "holy war" or rant as anyone else. But if they are going to be reading about our MultiValue environment, let's make it interesting. Make it something someone might want to spend some time working in.

So we've enticed our hypothetical 23 year old developer to give us a shot, and they have accepted our job offer. Now, how do we keep them?

That's where we will pick up in the next issue.

Clif Oliver

View more articles
menu
menu