Hiring new people may not be as complicated as we make it out to be.
My task this spring was to hire a developer. We knew which way the business wanted to grow and needed some additional full-time development help to begin with. We had some "legacy" IBM Domino applications that desperately needed a refresh in terms of functionality and web enablement, plus we needed to be more flexible in doing custom development to augment the primary ERP systems. Also, the ability for new apps to be built with a responsive design was a must-have, given our growing demand for mobile computing.
We've got an environment not unlike the average company using IBM i and Power Systems as the backbone of the business. In actuality, in terms of technological reach, Power Systems is much more than the entire skeletal system in our business. IBM i is like many of the other systems (nervous, muscular, circulatory, respiratory, etc.) combined.
With that in mind, a question came up when we were trying to really put a bead on what type of developer we wanted to hire. The usual "do we hire someone right out of college or pick up someone with a few years of experience" kind of questions were important and answered, but there was one question that hits close to home—not for us, but it seems like for many IBM i customers.
The big question was: do we want to hire a person with IBM i experience? Or even, do we want to hire someone who's familiar with IBM i at all?
On one side of the coin, the "IBM i experience" tag can be misleading. Is it an AS/400 professional using the IBM i moniker to sell themselves a little better? Is their experience rooted in green-screen applications with no flair for modern web development and database development standards? Those questions would be answered during interview time, of course. Also, and this is a big plus, having someone who's already a big IBM i advocate join us would be tremendous in terms of wanting to leverage the platform and justify it at budget meetings. You can't put a dollar value on that kind of passion for the platform.
On the other side of the coin, hiring someone right out of school could be a big bonus if they've got a solid foundation in what IBM i can do in 2014. With that being said, schools are not kicking out IBM i developers like they were when I went to college. I'm sorry to say that the school I graduated from is shamelessly teaching the exact same curriculum now, although I personally called their president and begged them to consider upgrading it two years ago. Last summer, I went back there for a quick chat about what they're teaching and left feeling really sorry for their proudly proclaimed "AS/400" style curriculum. They touch on the Integrated Language Environment (ILE), which is a total misnomer as they (for example) don't teach how to send prototyped calls to other languages. The RPG curriculum is entirely RPG III, staying close to the Original Program Model. The databases are still created with DDS source. When someone says they know what NoSQL means, it may mean that they know "no SQL" (as in zero) and live in the DDS world exclusively. And forget about an Integrated Development Environment (IDE) like Rational. It's still all green-screen through SEU. The horror!
This college's curriculum was all out of date when I was going there in 2000! I remember asking the instructors back then if I could learn the RPG IV syntax myself and do my term project in that language instead. They refused. So I did my term project in RPG III first, submitted it halfway through the term, and then re-wrote it in RPG IV with less code and more readability.
Truth be told, many people and organizations are improving the education curriculum at many schools across North America, with modern RPG and other modern languages and using IBM i as the platform. The word is getting out there, and curriculums are being updated. I just don't have any of those schools in my neck of the woods just yet.
My hope to find someone relatively local with a more fresh IBM i perspective was never put to the test. I decided we had to find a good developer first and then teach the fresh IBM i perspective myself. What did I want from a developer? The person needed be able to think logically and to read/learn the syntax of a number of different languages. They needed to be enthusiastic not only about development but also about using technology they may have never heard of before. A good, open attitude to learn and explore is everything.
It's not hard to get someone excited when you talk about the security, scalability, simplicity, and integration of IBM i and Power Systems. You're a PHP developer? Great. We can run that on this box. You want to do an application in Ruby? Great. We can run it on this box. Need an IBM HTTP Server tuned up really fast? Great. It's right here on this box, alongside the rest of the business. We don't need to put up a new Windows VM to facilitate your new web app. You need authentication for the application? Great. Use Domino LDAP. It's right here on this box. You want MySQL or DB2 or Derby or whatever for your database? Go for it. It's on the same box.
How many times do we hear about platform outsourcing or companies moving off the platform because they can't find people to turn the dials and flip the switches? How often do we hear that the IBM i skill set in the marketplace is waltzing into retirement?
IBM i isn't that hard. For its relative simplicity, there's almost a feeling you now need to be a guru to use it. There's a mystique about it. Maybe we're getting blinded by our own tales of how we "heard about a forklift smashing through the wall of a warehouse and a forklift blade punctured through the side of the ol' 400 and it still kept running."
We need to take a good look at our own perspective from time to time and make sure that we're grounded. Yes, RPG developers of years gone by are going or have already gone away into the sunset. If you've got a heavy investment in custom RPG code, you will either have to move to a vendor-supported solution or hire people who can learn it. The trick is to hire people who are open-minded enough to see the value of IBM i even if the front-end hasn't kept up with the times. Those are the people who can help breathe new life into your applications, not just maintain them.
I ended up bringing a talented developer aboard with zero IBM i experience. For the most part, that person has been living in the Zend PHP world and working with DB2 on i to pull in existing legacy objects and create new, modern SQL tables. In retrospect, the IBM i tools and experience are not what we needed. We just needed a good developer who can learn how to leverage the benefits of IBM i.
I have a few very simple guidelines as a development manager in an IBM i shop:
1. If you want to deploy something, it has to be on IBM i first and foremost. If you think it can't, call me.
2. See number 1.
Everything else, including shop standards, is up for discussion. We need to be open-minded after all, and good ideas come from everyone.