Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Offering a helping hand

by mr_mischief (Prior)
on Aug 02, 2001 at 17:15 UTC ( #101632=perlmeditation: print w/ replies, xml ) Need Help??

I'm the lead programmer at my company (okay, enough snickering ;-) and I've been asked to take a young VB programmer who wants to learn a more portable and more powerful language under my wing. At my small company, my position is pretty much writing 100% of the code on most projects, and checking up on small projects by other people. It could help me do more useful work if I can design a system and have this new potential hot shot give me subroutines to call. It could also be a nightmare of supervising someone with bad habits and trying to lay out a good learning track for him.

I've never been in a position to seriously guide the early development of a fledgling programmer before, and frankly it makes me a bit nervous. If anyone has suggestions on how to supplement the Llama and the Camel with real-life, face-to-face advisory sessions, I wouldn't mind hearing those.

I learned Perl with some background in other languages, the Camel, 1200 lines of source, perldoc, and a four-day deadline for major modifications (including 300 lines of new code). Although I like to jump into projects with both feet like this, I'm guessing I should take it a little easier on my student. What say the PerlMonks?

I know everyone learns differently and at different speeds, but there must be an art of finding how to teach a particular student a particular task. I hope to become at least half as good at teaching Perl programming as this kid hopes to be at learning it. Any suggestions on this are likewise welcome.

Chris

Comment on Offering a helping hand
Re: Offering a helping hand
by Masem (Monsignor) on Aug 02, 2001 at 17:29 UTC
    There's about as many ways to do this as there are people that read your question.

    My first approach would be to see what the young programmer has written already in VB, and find a task that is suitable for a possible conversion to perl. This means to try to avoid using anything GUI (which is really hard to do in VB, but possible). This way, your student already knows what the logic of the code should be and now should be understanding the perl engine instead.

    Another possible first task, if this doesn't pan out, would be to determin a much smaller version of code that is typical of the work this person might do in the future. For example, if he's bound to be a CGI/DB programmer, it might be a good idea to aid him in getting a very simple web-based address book up and running. If he'll be doing XML, have him work on simple client-server calls. Sure, the tasks are pointless to some extent, but the idea it to immerse the person in the language rather than take a step-by-step approach. Mind you, you should help the person break down on subtasks within the mini-project so that he doesn't need to focus on too many perl aspects at the same time.

    Of course, all this should be done after giving him sufficient time to read Camel and other books and practice on the topics in there. Ideally, when he is learning, you can point him to certain areas to look at closely, and he'll occasionally ask you questions or clarifications; this is counter to you standing over his shoulder at all times, as well as having him constantly at your desk asking questions and not learning on his own. Make sure to point him to other useful sources of perl info, including perl.com, newsgroups, PM (possibly), and other sources.

    -----------------------------------------------------
    Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain

Re: Offering a helping hand
by TheoPetersen (Priest) on Aug 02, 2001 at 17:34 UTC
    You hit it exactly with this statement:

    I know everyone learns differently and at different speeds, but there must be an art of finding how to teach a particular student a particular task.

    Unfortunately I'm not sure if anyone can teach that art, any more than they can teach the art of creating programs from post-it notes. It's something you learn by doing a lot (teaching or translating post-its), preferably by simple lessons, positive re-inforcement and not giving up. (Okay, you can give up on some :) This sort of training is much more like piano lessons than class lectures. It depends as much on your perceptiveness of the student as your talent as a programmer; perhaps more so, since good teaching leads the student into self-development.

    Go with your first suggestion, of giving the student small tasks that will result in callable code. That will help your project and emphasize good practices in the student -- compartmentalizing both the learning and the tasks. It is much easier to explain what is good and bad in a 15 line routine than in a 200 line script.

    Based on that experience, you'll see some lights coming on as the student applies lessons to things he already knows. (If no lights come on after a large number of lessons, proceed with the giving up.) That will clue you in on how to continue.

    Part of my previous job was to "modernize" a bunch of FORTRAN programmers into C and Perl. I made varying progress with each of them, because each was different and responded to help and lessons in their own ways. That experience emphasized to me what I'd found on my own, that there is quite a lot to learn in learning Perl, but the student can write useful code while climbing the learning curve if the lessons were short and built on things the student knew how to do.

Re: Offering a helping hand
by stefan k (Curate) on Aug 02, 2001 at 18:09 UTC
    Salve Magister :-)
    I just want to note some quick points. This is no very deep wisdom or something it all comes to you when you a) really think about this and/or b) got some experience in teaching coding. Plus I should note, that I'm surely not a coding wizard, I just get things done one or the other way ...

    The most important thing is to pick up the students where they are.
    (Masem already noted this in a way.) You should have a look at the code your student wrote in VB and you need to estimate his skills. Probably one could formalize this with a checklist you could got through which would contain points like

    • Does he use for-loops only or does he mix different kinds of loops
    • does he use "real" data structures like hashes or is he more the "keep 3 arrays synced"-type
    or something like that, but I'm definetley not the one to create this list. If you got a feeling for his skills you'll find the things to teach easier. Often people can learn a new language just from the differences to the languages they already know.

    Then you might be happy that you're going to teach perl, because you can stay with the language itself and don't need to introduce the compiler or other ugly stuff.

    Do you already have some typical quests in mind he will be doing? Well, then just teach those little tricks first. I have found that most people need the

    open(IN,"foo") or die "blah\n$!"; while(<IN>) { do_something_with_perls_special $_; ($probably,$they,$want,$to) = split(/;/); $probably =~ s/$change/$somestring/g; perform_some_test() and print "The Result\n"; } close IN;
    ..-Stuff for the first days (or maybe weeks).

    The Camel is not only full of knowledge, it's also really _fun_ to read. I made good experiences pointing that out. Though this may not count for an already experienced programmer.

    I once managed to teach a 16-year old school girl (who was good at maths but had no computer experience at all) a little perl coding (including the shell basics and some XEmacs) in just three days. At the end of the third day she was programming a little adress-database (yeah, flat file, but HEY! ... ;-) inluding regexp querys!!

    Well, then... Best wishes, all success (you won't need to luck ;) and happy teaching...

    Regards... Stefan

Re: Offering a helping hand
by Cubes (Pilgrim) on Aug 02, 2001 at 18:16 UTC
    This is a bit off-track from your question, but the single biggest obstacle I have encountered in similar situations is lack of motivation and/or time. Being charged with teaching a cow-orker something new, then finding out that your pupil isn't given any "work" time to use learning it and is not willing/able to do the footwork on their own time ends up enormously frustrating for everyone involved.

    Before you get too far into this project, sit down with your would-be student, his manager, and your manager (all together, or separately depending on your brand of office politics). If you're both willing to tackle this as a personal project, above and beyond your normal duties, that's great -- just make sure you understand each other's limits (can he call/email you at home with questions? will you set up regular lunchtime or after-work meetings?) If not, be sure your respective managers understand that teaching and learning take time, and that will impact whatever else you each have on your plate. Be sure you get clear direction on priorities, accounting/billing for the time you spend on this, and what sort of status updates and/or results they expect to see.

    About the only thing I can offer as a teaching suggestion is to try and get a feel for where your pupil is in his understanding of basic programming concepts. Make sure he's up to speed on data structures, algorithms (at least the idea of an algorithm and its relationship to code), program flow control, and some general OO stuff.

    If he learned VB by rote, copying and pasting and twiddling here and there, you may need to step back to the fundamentals of being a programmer before getting into the details of being a perl programmer. You might even have him do some exercises in VB (if you know any VB) to assess and/or teach some of this. Once he's got those things firmly implanted in his head, the specifics of any new language will come much easier.

Re: Offering a helping hand
by arhuman (Vicar) on Aug 02, 2001 at 18:17 UTC
    Beccause each learner is different, I'll give only guidelines :

    • Teach him the Perl syntax
    • Teach him the Perl idioms by asking him to code simple tasks (30 lines max) while you stay by his side and WATCH.
    • Show him how to do better (or at least more Perlish)
    • Try to spot his weaknesses, and give him the proper advice to correct it
      (some people don't catch recursion, some don't factorized the code, some don't use the appropriate data...)
    • Try to spot his strengths, and teach him how to have more fun with Perl by going a little more into the details
    • Iterate the previous step letting him handle bigger and bigger code...

    But most important for me, is to make him love Perl!
    Show him how powerful, easy, FUN Perl can be...

    "Only Bad Coders Code Badly In Perl" (OBC2BIP)
Re: Offering a helping hand
by melguin (Pilgrim) on Aug 02, 2001 at 19:57 UTC
    I agree with pretty much that has been said, but would like to add one thing: be a little humble. There are some things that matter and make for better programming, and somethings that are just your style. Perl is the king of accomplishing the same thing almost countless ways.

    While teaching and guiding in proper methodologies, be sure to allow your pupil to express his/her individuality. It's part of what make us human.

    Good luck, you'll do great.

Re (tilly) 1: Offering a helping hand
by tilly (Archbishop) on Aug 02, 2001 at 20:14 UTC
    Focus on finding something useful you can have him do early. If he isn't used to jumping in with both feet, it may have to be something small. Personally the first useful thing that I wrote was a simple program that just waited in an infinite loop on STDIN, every time you typed something in it would use the Win32::Clipboard module to read the clipboard into $_, it would do something, then it would paste $_ back into the clipboard. (Hint: you will probably want to turn \r\n into \n on the way in, and vice-versa on the way out.)

    The code was a complete mess. The program was dead simple in concept. The kinds of activities that it allowed were copying the clipboard to a named buffer (internally a hash), pasting back out, executing a buffer directly against the clipboard, prepending a string (eg "> ") to the beginning or end of each line, stripping off characters from each line, running the typed in code (eg a substitution) directly. That kind of thing.

    However it was something I understood and could use. The simple ability to use Perl to do mass edits to VB source-code gave me lots of flexibility that is old hat to anyone who uses emacs but was new to someone using VB. Trying to do mass edits gave me lots of opportunities to learn regular expressions. And all told that little piece of code, despite its faults, is the single program that I have written for myself that I have used the most. Copy text to clipboard, manipulate, and paste back. Comment out this block. Uncomment it. Take a list of items, turn it into the HTML for a dropdown box. And so on.

    I am not saying that this is the project you should give this person. But if you want him to learn Perl, it is good to find some way of making sure that that he uses it and continues to use it for a period of time. And the above piece of silliness worked for me when I was a rank beginner.

      Personally the first useful thing that I wrote was a simple program that just ... The code was a complete mess. That reminds me of something .... uhm ... It was my third post at the monks and my first programm: crush_data
      ... plus the first _hard_ lesson in TIMTOWTDI: merlyn showed the one-liner *grin*
      Those were the days...

      Regards... Stefan

Re: Offering a helping hand
by OzzyOsbourne (Chaplain) on Aug 02, 2001 at 22:47 UTC
Re: Offering a helping hand
by pmas (Hermit) on Aug 02, 2001 at 23:59 UTC
    ++ for mr_mischief. His method of learning perl (by jumping right into cold water and swimming) is not easy, but works best.
    ++ for Masem. Programming is (mostly) craft, and you can learn it by solving smaller problems.
    ++ for Cubes. Teaching will require your time, so all managers involved need to know about it and set priorities straight. Shortest way to hell is try to plese two different managers with different priorities (and I am speaking from personal experience with bad ending).
    I wanted -- cubes for proposing to exercises in VB. Why? Why not teach new concepts in language student will use? Firmly implant perl instead. IMHO. But time planning is double ++, so let it be. ;)
    melguin proposed to allow your pupil to express his/her individuality. I believe beginners, which need later learn to program in teams, most likely in team with you, much more important is to get used to discipline.

    My example: I have colleague who belives in complete freedom in programming. As a result, her programs have strange indent, naming variables does not make any sense and same database field has name abbreviated differently in different scripts (I have to read her programs and add features sometimes), and she strongly believes that 'use strict' is wrong because it breakes her "correctly working" code.
    My advice: is easier to learn correct way, than un-learn wrong way and re-learn correct after.

    You have unique opportunity to set some rules/coding guidelines, do not miss it. Let's be concerned about expressing individuality AFTER achieving mastery.

    Update: To former Visual Basic user, you need excellent visual debugger, othervise his first impression will be "perl sucks, VB is better". You are right, there is visual debugger for perl, check Open Perl @ sourceforge.net. Like Visual Basic, only for free. Now your student is hooked in.

    pmas
    To make errors is human. But to make million errors per second, you need a computer.

Re: Offering a helping hand
by petesmiley (Friar) on Aug 03, 2001 at 02:44 UTC
    I liked all of the responses. I thought I would add a few things. You can bring a horse to water but you can't make him drink :) A little overused, but guaging someones desire to learn is important. If they already know how to program and they want to learn perl, then they will learn it with or without you. If they're waffling in their desire, then more than likely they will never learn enough perl to use it on new projects.

    Also, learning to read the online documentation and books for perl is important. The chapter on references use of the word "thingie" had me a little puzzled. Odd, considering I'm good with pointers in C, which is sortof kindof related.

    Lastly, be willing to answer any question, regardless of how inane it is. Even the best minds are missing gears on some of the wheels ;)

    PS. I don't consider myself good as a teacher, but out of about 10 tries at teaching it, I had 2 successes. The 2 successes were the ones that really just wanted to learn it. They taught themselves pretty well :) Come to think of it, I don't think anyone really taught me a whole lot about programming. I think they just kind of pointed me in the right direction.

Re: Offering a helping hand
by petral (Curate) on Aug 03, 2001 at 13:49 UTC
    > perl -dwe0

      p

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://101632]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (7)
As of 2014-07-30 04:38 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (229 votes), past polls