I need a bit of mentoring advice

[mpennucci]

I recently (within the last 4 months) accepted a position sheparding/mentoring a team of new Perl programmers. I have been doing Perl development for around 5 years and I would consider myself competent, but by no means an expert in all matters. My team of 5 consists for the most part of Cobol programmers and business analysts, and have been developing very well over the last 4 months. We do have one individual who seems to be having difficulty.

This person came up the ranks as an operator and has been working with computers (mostly MVS systems) for the better part of 20 years, but they seem to be having problems grasping the basics of Perl programming, and of programming in general. They have done some Cobol programming, however when I assigned them a simple data conversion project, they were a bit overwhelmed. Even after sitting down with them and explaining a basic "divide and conquer" type of algortithm (to the point of open the input/output files, read in each line, unpack the line into its elements...) they were still very confused and overwhelmed.

I know that this person is trying very hard, but it just doesn't seem to be clicking yet. I have purchased a copy of the book Elements of Programming with Perl and I hope that this will help them achieve some sort of "Ah-ha" reaction, however I am looking for some sort of further advice/strategies that I can take to help them out.

Any advice would be more than welcome.

Thanks - Mike

[Ovid]

You may want to check out Mark Dominus's excellent article about his experience teaching Perl to COBOL prorammers.

As an ex-COBOL programmer, myself, I have posted a couple of nodes about this subject:

• COBOL vs. Perl
• Perl: Survival of the Fittest
These may give you some insight on how to proceed. However, I wouldn't show my nodes to COBOL programmers. They are not terribly flattering to the COBOL language.

Update: After reading jcwren's reply, I realize that I should have paid more attention to the "operator" variable. At an insurance company that I worked for, we had a few operators who were very good at being operators, but made a disastrous transition to programming.

One, in particular, caused us nightmares. I was one of the maintainers of a mainframe financial software package called IVIS. Normally, when the IVIS system would run out of memory, it would generate what is called a SOC-7 error. Unfortunately, this typically indicates a type-mismatch instead of an out of memory error. Somehow, this operator got it through his head that all he needed to do was "fix" our bad data. Then he would rerun these hideously complicated jobs and cause massive data corruption that would often take us days to fix.

Finally, we had to take the drastic step of not allowing any operators to touch our system, resulting in our getting pages at 3:00 AM when the system went down. We preferred this to having to work overtime for the next several days to make up for his inability to comprehend that sometimes you need to look beyond the surface.

Eventually, he became a Lotus Notes programmer and was put in charge of creating an application to manage our change control process. After a couple of months, he was demoted back to operator when the new change control process pretty much shut down the programmer's productivity.

Reluctantly, I must agree with jcwren. Assess this person's ability to even be a programmer. Just because you can fix a car doesn't mean you can design one.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

[jcwren]

So far, the answers presented mostly touched on teaching a COBOL programmer to write in Perl.

This persons problem seems to run a bit deeper, in that they don't understand the factoring process. It's been my experience that some people are just not cut out for programming. They may like computers, they may be able to use computers, and they may want to program, but unless you can factor a problem down to the level where it can be implemented, I don't think it really matters what programming language you inflict on them. Until we have languages that have a DWIMNWIS (Do What I Mean, Not What I Say) statement, they just won't "get it".

I would suggest that you get a feel for this person's current ability to factor problems, create a couple of scenarios, and see if they can solve them. You may have to break the news to them that they should stay an operator, or become a plumber. It's unfortunate, but the reality is that some people will never reach the level required.

This is also what differentiates people who are comfortable writing in assembly, and those that can only cope with high level languages. These people can conceptualize a "if ($a == $b)" in Perl, but not grasp the "get the address of $a, load the contents, get the address of $b, load the contents, compare, and branch if not equal" implementation in assembly.

--Chris

e-mail jcwren

[redmist]

This probably is not what you want to hear, but, in my experience, you can't hurry or force the descipline of programming.

When I taught myself Perl, I was *very* frustrated for many months, however you just have to Keep On Truckin'. I read and re-read all of my books on Perl, and scoured the web for a good place to learn (and found this one, fortunately). As a beginner, who is just learning the language, you have to have patience, the ability to laugh at yourself, and perseverance. It just takes time.

My advice would be to have patience with them, encourage them to ask questions (no matter how dumb they might seem), and to get them to code ALL THE TIME...even if it is just trivial little projects. It will give them practice.

redmist
redmist.dyndns.org
email::redmist

[little]

As I've read here in a previous thread that I can't find right now :-) also John Carmack learned perl from the scratch and didn't omitt the "Hello World" example.
There's always a reason to learn more and more but there are always examples of people we look to as they are "Code Gurus", and it's a better feeling that they had to learn it this way as well (at least for me it is). So learning in their way seems to have some advantage.
Simply spoken: ask for "baby" perl, this will do it's job, it will suffice, it will serve success, and it will improve by the time as the feeling for the new language arises.
my 1 1/2 cents :-)

Have a nice day
All decision is left to your taste

[adamsj]

Here's the sad story of how I came to be job hunting this week, with the names filed off:

For my first three years with XYZ Corporation, I, too, came up through the ranks from a help desk position.

My boss thought I had potential, asked about my background, and discovered I'd done some programming. He spent a morning giving me a "Basics of UNIX" course and another morning teaching me Korn shell, and then started giving me jobs he really should have been doing himself--I certainly didn't have the experience. However, I always got my stuff done, right and on time. Soon, I'd gone through sed and awk and settled on Perl as my primary weapon.

Pretty soon, I was really dangerous.

Our customer had several thousand stores, each with at least three big servers and a couple dozen smaller machines, heavily networked. I developed lots of stuff to run out there, in the stores and on the network.

Eventually, it came time for a job change, and I moved to another team, working for the same customer.

Disaster!

This job was not right for me--it was primarily a hardware position, and I'm not a hardware guy. I'm neither stupid nor incapable, so I hung in there and was competent--merely competent--at my job...which I grew to hate.

Our company found it difficult to fill positions in the area where we needed people, so the fact that I lived--wanted to live, in fact--right next to this customer, and that made me "valuable"...

...valuable enough, in fact, that, despite the obvious fact that the job wasn't right for me, my boss (with all the best intentions) made it very difficult for me to move to another job inside the company.

He had other motivations, all of them good, or at least innocent. He genuinely wanted to help me succeed at my job. He also was a new manager, and felt (accurately) that having someone successful fail on his team was a black mark.

He also has a screensaver that says "Money Money $$$", and, no matter how many times I told him that the raises he'd gotten me, and the raises he'd promised me, were not the way to motivate me, he could not hear this. He went on trying to motivate me, rubbing his fingers together and promising me that, eventually (which kept getting further away) he'd help me get into another job. He was a very well-meaning guy, and I liked him.

So the day came when I was called in on a Sunday afternoon to perform a very basic maintenance task--one I'd performed twice the day before during a preventive maintenance--which I performed beautifully and efficiently...

...on the wrong node, in a 128-node system of loosely coupled UNIX servers. I opened the node hot, pulled its memory board, panicked the node, restarted the system, and ended up with a three-hour outage to fix data corruption.

That's the only hardware mistake I made in over two years on the job, and it's the reason I ended up resigning.

My boss let his desire to help me, his need for a warm body on site, and his ego conspire to put me in a position where I made the sort of mistake I never made before. (I had an authorized back door to circumvent the change control process on my previous job, used it extensively for over two years, and never broke anything--ever.) The mistake was clearly my fault, but he put me in a position to make it, one I'd tried to get out of.

The moral of the story?

If the person you work with does not have the ability to program, then for his good, for your good, and for your company's good, you have a responsibility not to force him into a position where he will fail.

That being said, don't give up on him until you've tried your best--there's lots of good advice in this thread on doing that--but your best (and his best) will have to be good enough.

Good luck--and thank you for taking the responsibility to work with this person. You're doing the right thing.

[lolindrath]

I was one of those self taught programmers. I thought I was pretty good. I took a class in high school but the teacher let me go on my own since I had already learned everything she was going to teach. Well, now I'm in college and I'm awestruct. I'm taking fundamentals of computer science and I'm learning all these things I had never considered and never would have learned without a good professor.

The Moral of the story is: Learning takes time.

--=Lolindrath=--

[d4vis]

Sometimes people really don't know why they want to learn Perl. This may not be the case with your group, but I've found that in any teaching, making the subject relate to the student is always a good first step. This guy is an operator right? I'd suggest trying to figure out what sort of work he's been doing, and show him how perl can make his life easier. Lay out examples of what you want to teach that are relevant to what he's been doing for the last 20 yrs. of his life and it will be much easier for him to grasp the fundamentals. Want to teach him about data conversion? Figure out an instance where he's done manual data conversion in the past and then show him how to do it in perl. That'll gaurantee an "ah-ha" moment.

Folks with little or no programming background can learn and use perl, but it's far more difficult if they don't have some way to apply the theory to concrete examples of it's use.
I didn't learn Perl to learn Perl. I learned it to make my life easier. Now I'm using it to make other peoples lives easier too.

~monk d4vis
#!/usr/bin/fnord

ps. If that doesn't work, try beating them harder.

[cadfael]

I am a Database Administrator with Solaris system administration taking up the other chunk of my time. I am NOT a formally trained programmer in Perl or C or any other language except SQL. Perl is my tool of choice, though, when performing tasks related to my primary responsibilities.

That having been said, let me suggest that there are people born to program and people who have to work at it. I fall into the latter category. I RTFM, I practice, I ask questions of people who know more than I (including some young whippersnappers who could be my offspring), and from time to time I achieve that "Ah-Ha!" reaction.

Is there hope for your operator? Perhaps. Perhaps he/she will need to settle back into a niche that does not require programming. Or perhaps your operator will have that epiphany that many of us have experienced. It sounds like there are good resources at your place of work, and I hope the 4 others are as supportive as you are in trying to bring this person along.

-----
"Computeri non cogitant, ergo non sunt"

[OzzyOsbourne]

I didn't have a huge problem picking up Perl (It's like Othello: a minute to learn, a lifetime to master), but when I started programming, I just couldn't understand the concepts of programming itself (mostly, I kept trying to figure out where the variables were physically kept...sigh).

You mentioned that this person has done Cobol, but are you sure that they really have programing experience? If they don't understand programming, you have a much bigger project than if they don't understand Perl. If they do understand programming, it's a matter syntax and familiarity.

Anyway, I used SAMS' Perl in 21 days, and it really worked out to about 14.

-OzzyOsbourne