in reply to Teaching a CompSci student

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.

Replies are listed 'Best First'.
Re: Re: Teaching a CompSci student
by oakbox (Chaplain) on Jun 05, 2002 at 12:39 UTC
    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

[reply]

      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.

[reply]

In Section Seekers of Perl Wisdom