Mike Cain on Advocating For IBM i And Finding New Programmers
Paul Tuohy talks to IBM database guru Mike Cain about advocating for IBM i, where new programmers are coming from and hope for the future
Paul: Hi everyone and welcome to another iTalk with Tuohy. So I am here at the RPG and DB2 Summit in Dallas and delighted to be catching up with old friend and colleague Mike Cain. Hi, Mike.
Mike: Hi Paul. Thanks for inviting me here. It's always a pleasure to be here at the Summit.
Paul: Yeah. You are a hard man to tie down. So this is our what? This is our third attempt at doing this, third conference.
Mike: At least the third one so I apologize for that, but I am happy to be here.
Paul: OK. So Mike, one of the sessions that⎯well it's not a session that you give here at the Summit. It's more something that you host, you coordinate, and it's a thing that we call iAdvocate. So you want to tell people a little bit about what iAdvocate is, what that session is?
Mike: It would be my pleasure. So a number of years ago I was asked if I could share in some kind of structured fashion some of the experiences I've had and some of the techniques I use when confronted with concern about Power or IBM i or concern about continuing with you know RPG and all the good things associated with our platform. I thought about it and tried to basically come up with you know what are those things or techniques or situations where I'm trying to provide guidance, maybe illustrate things, let people understand that they have a lot more that they can do with the platform and it can still provide value. The result of that was a special session that was put on here at the Summit, a session that was at the end of the day where I would host a round table discussion if you will, kind of an open discussion about that topic and be able to then share not just from my own experience but from other people in the group what are the techniques, what are some of the ideas that one could use when advocating for IBM i or for the value that we get from using IBM i to solve business problems.
Paul: OK and as we know over the years that we have been doing it now, we have had some lively discussions. [Laughter]
Mike: We have.
Paul: OK so I'm going to ask you a really awful question to try and answer in such a short period of time but, do you sort of have maybe the top two or three points that you make to people? You know the advice that you would give people: So if you are going to advocate for the system, here are the three biggies. Or the two or the five or the ten.
Mike: So that's a very good question and I'll try to give a succinct answer and try to at least codify if nothing else some of the ideas I would use to answer such a question. The first thing is learn as much as you can about the system. I think if you are going to be an advocate for something, you should fully understand it. And unfortunately there are a majority of people out there that while doing great things are kind of stuck in their ways and they are not keeping up with all of the capabilities of their beloved platform whether they are using it or not; and so the first thing is to get educated. Come to something like the Summit; really understand what the capabilities and what the different sorts of things that you can bring to the table are at your disposal. So get educated so that then you can be a much more credible advocate.
The second thing is, and this has to do with a little bit of debate, logic, strategy and how you might argue a point and that is I tend to approach every problem first and foremost from what are the requirements, not I know what the solution is, let's move in that direction. So as an advocate instead of debating the solution or whining about why is it not i or why isn't IBM doing more or why didn't Paul Tuohy come and bail me out. The first thing I would ask is what are the requirements, business and technical. Now this might be your first problem because maybe people don't know what the requirements are and there is an opportunity to then gather those requirements. Once those requirements are gathered then we can start to understand what are the potential solutions that meet our business and technical requirements. And now we can take advantage of that newfound knowledge and wisdom about our platform to say, “Hey, guess what?” We already own the solution or we already have the capability in house to meet those requirements. That is how you come back around and advocate for the system and frankly advocate for your own value in using the system and be able to provide a solution, provide an answer to that question based on requirements which a) is very tough to argue with and b) if taken, if that solution is taken chances are that is going to be less costly, less risky, and will be much more elegant to be able to pull off in your organization. I personally believe that the majority of requirements in business today can be met by IBM i and if they can't, then go get that point solution but we are trying to avoid throwing out the baby with the bathwater but to understand how to make that argument, how to advocate correctly, we first must understand the requirements and then point out the fact that what we already own or what we already have the capability to do can meet those requirements.
Paul: Cool. So one of the things, Michael, at these conferences⎯I mean so the iAdvocate session, we would be running it at the end of the second day and one of the great⎯we do a lot of networking with the attendees and everything like that and we always know that before the iAdvocate session, we have a feeling for what the main topic is going to be.
Mike: We do.
Paul: So are you picking up anything? I have been picking up two or three conflicting signals from people that and that but have you been getting …
Mike: So that's a great question and we do observe the audience obviously and we observe the hall talk, the hall chatter and what is interesting is I think most people make the assumption that the programming population who are working on IBM i or specifically coding in RPG is aging. I know around the world I have spoke with a lot of people who called that out specifically and obviously there is an undercurrent here of where are we going to find the next set of RPG programmers or where are we going to find the next set of advocates for this platform. Honestly, that always concerns me because my first answer is well, train them. What is the problem? Programming is programming. I am really excited because we had a conversation earlier, Paul, where we were talking about this very subject and you came up with this experience that said yeah, I proved that. I was able to take some young kids and teach them how to program⎯don't even say RPG. Teach them how to program on this platform, and boom, they got it. I would like to hear more about that because I think this was a fantastic story to be honest.
Paul: Yeah I mean this was something and I had mentioned it briefly in a previous iTalk that last year I was asked to do just a one-week crash course in RPG for a bunch of students at Gothenburg University in Sweden.
Mike: So these are young people?
Paul: Yeah I mean young people. They were all studying, well, I think there were a couple of guys who were post grads who would have been sort of in their⎯I mean they would have been old. I mean they were maybe late 20s. OK and, by the way just to put this in context before I get back to the Gothenburg one, just last night at the dinner, we have maybe what 130-150 people there and we asked a question. We said how many people are under the age of 30 and 4 people stood up.
Mike: Yeah. Wow.
Paul: Four in the room so it is a thing that we have a ... we are mature. We are a mature group.
Mike: Yes. Yes.
Paul: With that. Sorry, yes coming back to the Gothenburg one so this was a sort of crash course. I want to say like the oldest were in their later 20s. Most of them were maybe in their second or third year of college.
Paul: And they were doing IT. They were learning programming; you know degrees in computer science, whatever.
Mike: Latest and greatest.
Paul: Latest and greatest. And this course was not part of their curriculum. It was offered as an extra if they wanted to do it and there was a promise maybe of getting some intern work with different companies around Sweden, the company that organized the software, the company had organized all of that along actually with COMMON with Data 3, the guys there. I had asked the question before I went. I sort of said well what exposure will they have had to the platform and they said oh, we'll have covered that the week before. What I didn't realize was what they had done was the week before was that on Friday afternoon one of the guys from the software company came in and he gave them a presentation for a couple of hours about what IBM i was.
Mike: 30 years of technology boiled down to one or two hours.
Paul: One to two hours and by the way, that may be unfair. Maybe it was an afternoon. It could have been four, right?
Paul: And before that, they had never heard of IBM i.
Paul: They didn't know what it was. As part of that, he told them where they could download a copy of Navigator and they could download a copy of RDI.
Paul: And they should have it installed on their PCs on their laptops for Monday morning when I was coming in so that is what I walked in to. These were guys, they knew how to program in JAVA, PHP, or C, or C++ or Objective C, whatever they were learning on their courses, and by Friday, they were doing screen maintenance programs.
Mike: Wow. In RPG?
Paul: In RPG.
Mike: On IBM i?
Paul: On IBM i with zero problem. Now don't get me wrong. These guys weren't ready to start you know changing your accounts payable and accounts receivable or web enabling it or anything like that, but in terms of learning a language. Now of course we are talking complete freeform RPG here.
Paul: We are talking modern RPG with that.
Mike: With modern development tools as well?
Paul: With modern development tools and that was it. Because of the modern development tools, RDI I mean most of them were used to it because they are used to using Eclipse. OK, so learning the tool was easy. The structure, I mean I did explain what source physical files were. They looked at me a bit blankly and of course, they go into RDI and it just looks like a standard tree structure so that is fine. OK. They had absolutely no problem with it. They had no problem with the green screen because they would go to run a lot of the programs and things like that. It was nothing. They would say oh, look, that is quite a nice command interface. It has menus. Wow.
Mike: And I have to imagine at the end of that week, they felt like they just had another valuable tool in their tool kit. It was just another language.
Paul: That was it and it was one of the questions I was asking them. At the end, I was sort of saying well you know how do you feel about RPG now and their reaction was-they were looking at me as if I was an idiot. They were going like well what do you mean how do I feel about it? I mean how do you have a feeling about it? I think one of them sort of said to afterwards he said well if you were talking to a carpenter, would you have ask him how he feels about his saw and how he feels about his hammer?
Paul: You know?
Paul: And they were looking at me. I mean really it has been a long time since I felt like that with a bunch of people looking at me as if I was a true idiot. Mike: So at the end of the day I think part of this is a phenomena that we are making a mountain out of a molehill and if we approach it the way you did, give the young programmers credit that they can figure this out, give the language and the tools credit that you know they are modern and get over the hang up that this is RPG and we happen to be using it for 40 years. It is just a modern language⎯
Mike: Like any other language.
Paul: Yup. I have got to tell you one of the interesting things as well is that when you talk to them about the language itself. So I would ask them so what did you like about it? What did you dislike about it? You know so they would come up with horrible things about RPG you know like things it doesn't use curly brackets. [Laughter] I mean we are down to that sort of nuance with the thing right?
Mike: It is a style thing I guess.
Paul: It was a style thing but I mean like that was sort of the thing but I think one of the cool things that I got from a few of them was they sort of said well, you know, they sort of said, well you know some stuff here. This is a lot easier than Java.
Mike: There you go.
Paul: It is when you come to the business bits and that is what RPG is good for. These kids⎯actually, interesting: I was just at WMCPA. We had a round table there and of course, you know that area, you've got Jim Buck and all his students and of course, they were all there.
Mike: They're in Wisconsin.
Paul: In Wisconsin and he has this sort of all these bunch of students. They were saying the exact same. These questions were asked at the round table and when they were directed to me, I would say well I'm not the one to answer it. I would ask them again and say well what do you think of this? They were all again looking at us as if we were idiots. You know I mean to them it is just a language.
Mike: So allow me to connect a couple of dots. So here, if we got back to requirements and ignore the solution i.e. the solution is we need to move away from RPG and thus IBM i. If we go back to the requirements and say we need to find some new, young, hotshot programmers to be the next wave of RPG, CL, database, whatever on IBM i, that’s the requirement. Then how do I solve that requirement? You just gave us a very good example of one way to solve that that is going to stick and that is just approach it as another educational opportunity. Go find the candidates, train them, given them credit, give them the right tools in the right environment and off we go so once again don't focus on the solution i.e. we got to throw this out. Focus on what are my requirements and then what’s the best way to attack that problem like you did and this proof point I absolutely love, Paul. I think this is fantastic because it is a proof point. It wasn't we're just saying it. You did it and you got feedback.
Paul: Yeah. Yeah and it is. Not only that, you talk to Jim Buck. You talk to his students. It is everywhere that this is happening. All the students say it and where you see this where they go into companies where they actually get the jobs, they start working. It's not a problem, you know? And I tell you we have a lot to learn from these kids.
Mike: Yup. Amen.
Paul: I learned more that week about how to do things. Now of course I didn't let them know I was learning stuff. [Laughter] I was constantly going oh, I knew that.
Mike: Well, that's the beauty of it really. I think we all need to take some of the young folks under our wing, share our wisdom, but at the same time let them embrace the modern tools, the fresh technique and not get caught up in the history if you will.
Paul: Oh, yeah. Very much so. Very much so.
Paul: OK, Mike, well listen. Thanks as always for taking the time to talk to me. Now of course probably at the iAdvocate session this evening nobody will mention programmers. [Laughter]
Mike: Well we covered here Paul so yeah.
Paul: OK, we've got it. If anybody asks, we'll just refer to the iTalk. OK then.
Mike: Thank you very much sir. I really appreciate it and as always it is a pleasure to be here at the Summit.
Paul: OK, thanks Mike. So that's it for this iTalk everybody. Tune in for the next one. Bye for now.
Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.