Clif Notes-New Blood Part 2
In part one, we discussed some of the things we could do (and a number of things not to do) to attract new blood to the MultiValue community. Now let's talk about some of the things we need to do, not only to attract Millennials to our shops, but also to keep them. It does us little good as a community if a bright, energetic, young developer joins our team, suffers their own version of "burnout," and two months later quits because they are bored to tears. Or if they are embarrassed to admit to their cohorts what they do for a living.
The first thing we need to understand is that Millennials are coming from a different perspective than a lot of the previous generation did. (And definitely different from the previous-previous generation.) For example, a job is not just a job. It is not just a way to make money in order to buy the Beamer or the newest catamaran. Millennials expect jobs to have "meaning." Now the individual's sense of what "meaning" means is as varied as it is in the previous generations. But whatever it is to a particular individual, as a group they expect a job to be more personally fulfilling than simply collecting a paycheck and busting their butts for a promotion. Remember, Google is your friend. Go out and do some searches and you'll find numerous articles about how this group is frequently willing to take a lower paying job that has a better working environment, better social interaction, and what they perceive as a higher company social conscience.
Now unless you are in an upper management position in your company, possibly even a C-level, there's not a whole lot you can do about the company's social conscience thing. But there are some things middle management can affect that will determine whether or not a newly hired millennial continues as a MultiValue developer. Everybody on the development team plays a part in determining whether the new developer will stay or bolt.
Let's take a look at what the younger crowd thinks about another "big mainstream" environment as to its desirability for even a short term employment, let alone a long-term career.
You can see it here, in a couple of posts that I found right off the bat while I was doing web searches. (In other words, they popped up in the first two screens. I didn't have to go digging all night for these.) They show why young people don't want to work with mainframes. As you read this I am going to ask you to mentally substitute the word MultiValue for the word mainframe.
All the italic emphasis is mine to highlight the points I think should slap MultiValue developers in the face. A lot of what we are accused of — old technology, outdated programming tools, dinosaur mindsets — are thrown at the main-framers, also. So take a look at these two posts about why young developers want to avoid mainframe jobs.
"In a competitive IT world if you spent the couple of years it would take to actually come up to the beginnings of reasonable speed in mainframes, you wouldn't lose your previous skills but you'd automatically be less appealing when looking for other work , just like if you'd spent two years doing forestry or managing a Starbucks: looking like you're out of the loop even a little bit does you no favors when being compared to someone who doesn't look that way. "
- Matthew Frederick May 12 '11 at 9:36
"I'm a young programmer. I've never seen a mainframe, never had a sandbox/virtual mainframe to play with, never had a friend come up to me and say, "This is really cool, check it out! ". I see the web every day, there's readily available - and free - webapp dev learning tools, and all my friends are doing neat stuff in it. Which am I going to choose? "
- Beekguk May 11 '11 at 19:51
Do you see what I mean? How on earth do you expect to retain a new developer who has had a computer and always-connected Internet most of their life? A developer who spent their time in school studying to work in that modern environment of point and click, drag and drop, always available websites, and now mobile apps? Do you really think that they are going to be satisfied working in a shop day in and day out coding in BASIC while their friends are enjoying constantly learning about new technologies and working with the latest methodologies and frameworks?
Newsflash, people. You can't pay them enough to do that.
Fortunately, we are now at a state of affairs on most of the MultiValue platforms that we don't have to. There is no reason on earth for a shop to keep developing telnet-based green screen programs when there are a number of modern tools available for desktop, web, and mobile applications. But yet I continue to hear the same old arguments about modernizing things being too expensive, less efficient, etc. that I have been hearing for more than the last 10 years. (Yes, I know there are exceptions - different discussion.)
You expect a 25-year-old whiz-bang developer to stick around in that type of an environment?
Now I will admit that we have some things going against us in this battle for young minds that we really can't do anything about. For example, the very name of our programming language. BASIC. It doesn't matter whether we call it MultiValue Basic, Data/Basic, U2 Basic, QM Basic, or whatever. That B-word will kill us every time. As Brian Leach pointed out in one of his recent Spectrum Magazine articles, even Microsoft's Visual Basic has the same baggage of being considered a toy language because of the B-word. "Serious".NET developers work in C# and leave Visual Basic to the hobbyists.
Well, I'm afraid that's just something that we're going to have to live with for now. There have been a number of suggestions over the years of how to deal with that. But when you consider the cost and resistance of changing a name that has its roots in the 1970s, well, good luck with that.
But one of the things that we can do is to present it to the younger developers as not being the primary development language for everything but more like a server-side scripting language. There is no reason why the new developers can't be developing in something else (C#, Python, Java, etc.) on the client side while the traditional MultiValue developers are providing them with subroutines on the server-side to call for the data access and business logic.
Now we certainly hope that we can entice at least a few of the young developers into learning the server-side language. We need them not only to be able to do their own server-side programming when people retire or move on but to help maintain some of the "inherited" code while we are slowly modernizing everything. So by whatever means, we need to entice them into learning this programming language. So we sit down with them, edit a program, and start to go through it, explaining the features of the language.
After recovering their breath, picking their jaw up off the floor, they are likely to go running for the HR department to turn in their resignation. Yelling as they run down the hallway, "are you <explicative deleted> kidding me!? THIS PRODUCT HAS ITS PROGRAMMING DONE IN ALL UPPERCASE!".
Well, you've just lost another one. All of your talk about how advanced and easy the programming language is to use has been blown out of the water and forgotten because it looks at first glance just like COBOL, FORTRAN, BASIC, etc. In other words, a language that will destroy your career and make you unemployable if you work in it. Just perception? Maybe, maybe not. But to most people, not just Millennial new software developers, perception is everything.
How many times have you heard someone in the sales department quote the old line, "You sell the sizzle, not the steak?"
We will talk about this issue in part three.
