The two best things you can do are:

1. Give him time to read, and
2. Give him a sandbox for toy projects.

Most companies that deal with software treat "training" roughly the same way they treat "voiding one's bowels". They acknowledge that both are necessary, but would prefer not to see either one happen right there in the office. But where federal health and labor laws force companies to provide bathrooms and allow employees to use them, there's no corresponding mandate to support training.

In other words, most companies talk a good game of training, but don't actually do anything to support it.

If you want to break the pattern, start with the one resource most vital to any educational program: time. Set aside some amount of time every week -- 2-1/2 hours (half an hour a day) is usually good -- and tell your student that he's to spend that time researching some Perl-programming-related subject. Have him keep a research log every day, where he writes down what he wants to get out of each day's reading before he opens the book, then makes notes about what he finds while he's reading. At the end of each week, have him go through that week's log and show you the progress he's made, then tell you where he wants to go in the next week.

That cycle will teach him a lot of valuable skills above and beyond what he learns about Perl per se: setting goals, tracking progress, and making that progress visible to someone else. He'll also get valuable experience with the mechanics of business communication.

Personal aside -- one of the most valuable things I ever learned about living in a corporate environment was how to sit still in meetings. I was in a semi-formal meeting with the departmental VP, and was absently cracking my knuckles while we waited for things to get going. Greg, my VP, looked over at me and said, "You're fidgeting, Mike. Stop. It costs you points in this setting." Since then, I've sat through any number of meetings, taking note of the giggling, tapping, coughing, and babbling of other people around the table, and quietly noting just how right he was.

Toy projects are the other half of the training agenda, because they provide that all-critical resource: freedom to fail.

You can't teach people anything valuable in a production environment, because in a production environment you can't afford to screw up and throw the whole thing away. That means you can't stretch, or make a serious commitment to anything that doesn't have a good cost/benefit/buck-passing/deniability ratio.

The production environment rewards hidebound conservatism, failure that distributes the blame across a large number of people, and failures that are too complex to be summed up in a half-dozen bullet points. It mostly ignores ordinary success, and punishes heroic efforts by assuming they can be done again on demand. None of those are useful for someone who wants to learn.

A toy project is something you can afford to fly straight into the ground, just to see what happens. You can learn a lot doing the post-mortem for such projects, just as the auto industry learns a lot from crash tests. You have to be able to send the car into the wall at 60mph, though, and you won't get anywhere with some beancounter clucking over your shoulder, insisting that you get N+1 tests out of every car.

So give your student time to do research, and make him pay for that time by showing you what he's learned. Then when he's learned enough to need some practical experimentation, give him the freedom to try things and fail, and make him pay for that by telling you what he tried, and what happened. You can hardly keep people from learning under those conditions, even if you have no idea what they're going to learn when you set out.

If it's just a 'toy' project, that's kind of DE-motivating. It should be useful, because then he can see the impact of a finished tool in a work environment providing real benefits to his co-workers. Some suggestions:
• Some kind of auto-updater for a web site. Maybe form-based/CGI. Put the data into a MySQL database and you've got most of LAMP all in one project.
• A Module that does something basic. Maybe as simple as moving files between servers. This will introduce him to Perl's version of OO and address portability issues.
• Installing Everything was a pain in the rumpus. You can baptize him by fire by having him set it up. (introduction to MySQL, XML, mod_perl, CGI, and how to deal with memory leaks).
• Maybe a news ticker for a web site. Depending on the source, this might be good for XML-Perl learning. Perl on the network.
These are just ideas, I'm sure you've often thought, 'Gee, I wish I had a script that did that automatically' but just didn't have the time to sit down and write. Now is a chance for you to get your tool and someone else to learn from it.

Start him on the path of use strict from the very beginning, (of course). I've found that books are good, in general, but only when they support me in completing a task. If the task is compelling, learning how to do it is easy.

oakbox

If it's just a 'toy' project, that's kind of DE-motivating. It should be useful, because then he can see the impact of a finished tool in a work environment providing real benefits to his co-workers.

Hrm.. Offhand, I'd guess that you've never had a side-project metastasize into something officially useful. Trust me, if you want de-motivating influences, the 'uselessness' of a toy project doesn't begin to compete with the exasperation of having a personal project declared 'valuable'.

It all goes back to the core issue of freedom to fail. You don't crash a program that all your associates are using. You don't rip out a bunch of working procedural logic and replace it with admittedly bad OO code, just to see what will happen. You don't stretch. You don't explore. You don't try anything new. You don't do anything that will damage the code, because the code isn't private to you. It's a service you provide to the community, and you don't want to degrade that service.

There are social hassles: Any time you release a piece of software to the public, you take on the burden of supporting that software. Nobody will take the time to learn your conceptual model, and everyone will want you to adopt theirs. Everyone will come up with their own wish-list of features they think you should add, regardless of whether those features are interesting to you, or even technically possible. And everyone will bitch at you, because they feel (with some justification) that using the code gives them a stake in the project.

There are organizational hassles: If management decides something is useful to the company, it no longer belongs to you -- it belongs to the company. Intellectual property issues aside, when a company annexes your work, you no longer control that work. Your bug-ridden, pre-beta code goes into deployment whether you want it to or not, because management expects it to work. You don't get time to fix bugs, because management has its own wish-list of features it expects you to add, and won't give you enough time to do any of them properly.

I've been pushed down that particular flight of stairs a few times. Often enough, in fact, to have adopted the rule, "never show a manager a working beta." Every time I've broken that rule, I've regretted it to the tune of at least a hundred hours.

Your definition of 'useful' translates to 'production code', albeit informally, and the production environment is just a lousy place to try and learn something new. Learning something new is hard enough as it is, without adding the hassles of customer support, or the risks of managerial intervention.

What a toy project should be is interesting. It should generate enough of a conceptual itch that the person doing the project will go after it like a terrier chasing a rat. Interesting is what drags you into the unknown. Useful is what happens once the unknown has been mapped, and is no longer quite so interesting.

Meta-advice:

My experience (YMMV) is that some fresh grads can have strong mental armor around their egos. Teaching (well, Learning) can't happen until the armor weakens enough for them to admit that they still have a lot to learn. I've had to take a couple of fresh grads and let them fail miserably on small, but tough, projects.

If you've got a guy who is eager to learn, you might not have to do this.

I, uh, speak from personal experience on this. I had to have my head pounded into a wall a couple of times early in my career, and at least once later.

In Node difficulty level, hagus mentions Unskilled and Unaware of it which would be useful reading if you have to deal with someone who is unaware of their own weaknesses.

As a programmer of 20+ years thru Basic, COBOL, Fortran, C, REXX, C++, Java with smatterings of C-shell, Bourne shell, AWK, SED and more, & just 1 weeks aquaintance (all be it heavy hours and with real goals), I am finding this transition the worst ever. Maybe I'm just getting old.

I saw people advocating the PerlDocs........I cannot agree. I have so far found them far to terse, full of religious terminology (magical, autovivication, globbing etc.) and (as someone without much unix background) far to full of explainations that refer to (what I assume) are common, well-known Unix terminology, references and explaination-by-comparison with Unix concepts, to be of much value to me.

See Perl IO::Dir or IO::File (actually anything in the IO::* packages) for examples of this. Try and imagine these pages as explainations, if the Unix stuff isn't part of your experience set.

I suggest (and will be doing myself) getting the books first.

I then agree with most of what other people have been saying ...Set him writing *real* code ASAP and give him the time and space to experiment. Don't give too long a timescale for the first project up-front......no pressure means no incentive in my experience.

BrowserUk brings up a really good point. It is important for this new student to know about Perldoc, how to use them, and what's in them, but from the description of this student's studies (Java and VB) he learned on a Windows platform. A lot of the documentation still relies on *nix and C ideas, though this has been decreasing over the years.

This doesn't get mentioned often, so I thought I would second BrowserUk's comment.

Some obvious resources are here, 'Learning Perl', various other O'Reilly books, and some of the New Riders books on MySql. These I have. I plan to turn him loose with Learning Perl, and make him work through the exercises. Any more specific suggestions for bringing people from a Java/VB background to a working knowledge of Perl fairly quickly?

If you have a programming background, Learning Perl can be very boring at best ;) That is, if you do all exercizes. Let him read it, and have it followed by Programming Perl optionally, but no matter what: teach him to use perldoc, and use it a lot. Make clear you rather have him read very good documentation than code by brute force. The time "wasted" on reading is gained elsewhere.

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

You're right. One more point to be made (as someone who worked through all the exercises in Learning Perl and found it really helpful) is that it does not adequately handle the topics of data structures and object orientation. Familiarize your student with Perl's data structures fast or he will be yet-another-bad-perl-hack.

~~~~~~~~~~~~~~~
I like chicken.

My favorite for learning data structures in perl is "Mastering Algorithms with Perl" from O'Reilly. Since the data structures are critical to the algorithms, the book takes some time to build them logically. Highly recommended.

Spring: Forces, Coiled Again!

If his background is Java, I'd say a critical part of his development will be to learn that in Perl the rules, especially the rules of object oriented programming, are largely up to the programmer to legislate. He is likely used to relying on the compiler to restrict heavily what he can do, and mistakenly conflate this with what he ought to do. TheDamian's book Object Oriented Perl is a must have for someone in the position you describe.

"The only way to learn a new programming language is by writing programs in it."

Of course given that it's summer right now that may not be an option for you.

I tried to teach myself Perl, got enough under my belt to do what I was trying to do, took the class and realized exactly how much I didn't know about Perl.

Hope that helps!

Some people fall from grace. I prefer a running start...

• Spend about an hour covering the basics of Perl (syntax, the variables, module concepts, etc.)
• Assign a project that will be small, challenging, and in the general direction of where you need to go with your projects.
• You are going to have to allow this person some time to learn, and if you're committed to doing that, then I suggest that you request that the person get an account on Perl Monks. I dabbled in Perl and fought though some of the books, but until I started to participate in Perl Monks, I didn't quite understand the full caliber of Perl. Perl Monks has a large base of users, information, examples, and is just as valuable to me as any book or document. When I'm stuck, I read the books first, and then go to Perl Monks.

hth, andy.