Beefy Boxes and Bandwidth Generously Provided by pair Networks Bob
more useful options
 
PerlMonks  

Teaching a CompSci student

by astaines (Curate)
on Jun 04, 2002 at 22:13 UTC ( #171649=perlquestion: print w/ replies, xml ) Need Help??
astaines has asked for the wisdom of the Perl Monks concerning the following question:

Hi, I've just acquired a nice shiny new CompSci student, with about a years experience. His course uses Java and Visual Basic as exemplars of programming languages. He has also taught himself a fair bit of Oracle. He's clearly bright and well-motivated.He's coming to us for a year's work placement.

We need some database organisation (we'll use MySQL), and some simple web interfaces to same. We'll run all of this on Apache on Linux (what else!). All going well we'll set up a simple web portal built on Slashcode or Everything in the future.

So - to the question - I need advice on how to teach this guy. I know Perl fairly well, but my own background is in clinial medicine, not programming. Our student is doing this to boost his CV and gain experience. I have a responsibility to him, more than I would have, say, if I could afford to hire some of you lot.

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?


--
Anthony Staines

Comment on Teaching a CompSci student
Re: Teaching a CompSci student
by Juerd (Abbot) on Jun 04, 2002 at 22:23 UTC

    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!
Re: Teaching a CompSci student
by brianarn (Chaplain) on Jun 04, 2002 at 22:32 UTC
    Much like Juerd said, Learning Perl is good but will get stale fast for someone with a programming background. Don't get me wrong, I like the book and all, but working through all of it seems like it's burning otherwise useful time.

    Teaching perldoc is good, I'd also recommend reading perlman:perltrap (at least the first part, I'm sure some parts of the C traps carry from Java well), which I found useful as a CS student transitioning from C/C++/TCL to Perl. Heck, my first question here was answered in perltrap.

    If you've got some money, I'd actually recommend picking up the Perl CD Bookshelf 2.0 from O'reilly - it comes with Perl in a Nutshell in deadtree copy, and five books on CD that are handy to search through and whatnot. The first Perl CD Bookshelf had six books, and I don't recall what was eliminated, but CD Bookshelf 2.0 has Programming Perl, Perl in a Nutshell, and the Perl Cookbook, which is excellent to get some understanding from.

    ~Brian
Re: Teaching a CompSci student
by dws (Chancellor) on Jun 04, 2002 at 22:49 UTC
    I've just acquired a nice shiny new CompSci student, with about a years experience. ... I need advice on how to teach this guy.

    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.

Re: Teaching a CompSci student
by djantzen (Priest) on Jun 04, 2002 at 23:45 UTC

    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.

Re: Teaching a CompSci student
by Steve_p (Priest) on Jun 05, 2002 at 00:13 UTC
    To quote Kernighan and Ritchie,
    "The only way to learn a new programming language is by writing programs in it."
    While going through Learning Perl is important, there are a couple other standard documents he needs to read. Have him go through perlref and perltoot. But, it is probably more important to get programming quickly. Think of some mundane task that needs automating, and have him design and implement an object oriented solution. This should give him the background in Perl to take over quickly.
Re: Teaching a CompSci student
by mstone (Deacon) on Jun 05, 2002 at 00:43 UTC

    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.

Re: Teaching a CompSci student
by BrowserUk (Pope) on Jun 05, 2002 at 01:14 UTC

    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.
Re: Teaching a CompSci student
by Popcorn Dave (Abbot) on Jun 05, 2002 at 04:14 UTC
    Oddly enough, the one suggestion I didn't see here, and it may just be because it's the wrong time of year, is to look at your local community college and see if they offer a beginning class in Perl.

    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...

Re: Teaching a CompSci student
by zakzebrowski (Curate) on Jun 05, 2002 at 12:14 UTC
    Personally, I would do a couple of things:
    1. Show him how to use perldoc
    2. Show him an example program (something simple)
    3. Show him search.cpan.org
    4. Give him the task. At the end of the day, return and see how much (if any) process was made.

    Good luck (quick comments as I run off to do a build... :))

    ----
    Zak
    "There is no room in this country for hyphenated Americanism" ~ Theodore Roosevelt (1915)
Re: Teaching a CompSci student
by Mission (Hermit) on Jun 05, 2002 at 12:54 UTC
    To teach Perl is a difficult chore. Perl is so flexible, that most people have many different ways to do everything. Just look at the golfing that goes on around here. My suggestion is to not underestimate this individual. The CS students who work for me (granted this is before they have their degree) at the university, have dabbled in enough languages that after about their third to fourth language, they start to realize that the syntax isn't as important as the logic, planning, and understanding the 'vocabulary' of the language you need to write with.

    I agree with what everyone else has said so far (BTW: ++@_) and I'd like to add just a couple of thoughts.
    • 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.
    I wouldn't be too worried about this person picking up Perl. Just make it clear that, "In this office, we use Perl. Learn it." They will thank you for it later.

    - Mission
Re: Teaching a CompSci student
by bserfaty (Novice) on Jun 05, 2002 at 23:46 UTC
    I pretty much agree to most of what been said, especially about the "sandbox" projects.
    I would like to add, though, that since he is fresh from school, doing too much "scripting" stuff and exercises might fade his object oriented knowledge.
    My suggestion is to encourage object oriented Perl solutions when possible, and anyway, to see that he uses the more advanced language features so the work isn't simply done, but a real Perl (and programming) experiance is gained.
Re: Teaching a CompSci student
by andye (Curate) on Jun 06, 2002 at 12:57 UTC
    Also, get him to visit Perlmonks or other online forums, go to his local Perl Mongers (http://bath.pm.org/map/), maybe send him to a conference (http://www.yapc.org/). All good community-of-programmers type stuff.

    hth, andy.

Re: Teaching a CompSci student
by feloniousMonk (Pilgrim) on Jun 06, 2002 at 14:22 UTC
    Freedom to fail, as mentioned above, is paramount.
    It exposes your flaws as well as build confidence.

    Something useful, but not critical, may be the best approach
    When I started my current job a while back, I had a heavy
    C background and a bit of Perl. Not until I started a
    relatively small, useful, but not critical project did I
    realize what my level of Perl knowledge was.

    I ended up rewriting the code a few times, breaking it a
    couple times, and finally coming up with something I'm
    happy with. All throughout, it worked fine but I
    was never afraid to stir up the guts a bit because
    life did not come to a grinding halt if it broke.

    I learned more from that project than the more interesting,
    mission-critical apps that simply must work
    at all costs.

    felonious --

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://171649]
Approved by MeowChow
Front-paged by rinceWind
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (10)
As of 2014-04-17 22:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (458 votes), past polls