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

Adult learning problem

by jepri (Parson)
on Apr 05, 2002 at 05:51 UTC ( #156829=perlmeditation: print w/ replies, xml ) Need Help??

As I mentioned in a slightly earlier thread, I was teaching my flatmate Eiffel for his comp sci course. What I didn't mention was the trouble he was having with basic concepts, and I think a large part of it was the way he was approaching the subject.

I couldn't get him to write simple programs like "Hello World" because they were 'too simple'. He wanted to crack systems right away, like the characters in the movie 'Hackers'.

I've noticed this attitude amoung a number of adults - the idea that having been alive for 20+ years gives someone the innate ability to - I don't know - code network apps, or use power tools, or fly an aircraft, all without prior training.

Back to the case at hand. I could get my friend to following the code on the screen with his finger and saying things like "if this is true, jump to the end, otherwise go into the block". But the moment I turned my back he'd just be mixing random bits of code in the worst 'shotgun' debugging style.

His main problem was conditionals at one point. He just couldn't quite get the hang of the program flow, or code pointer concept. So he'd put things inside conditionals that weren't meant to go there. He thought that because they were still in the surrounding loop construct they would magically get run somehow, each time the computer went through the loop. And because he wouldn't do something as childish as put his finger on the screen and trace, he'd miss the important logic statement that was tripping him up.

He's got a little better, but he still won't write little mini-programs to test ideas. He's going to fight to the last against doing something 'childish', even though I assure him that when I'm coding professionally I'm doing little test scripts more than I'm working on the 'real' program.

I'll leave you all with the suggestion that you should code something 'silly' as often as you can. In Perl you are lucky because it is legitimate to write silly little scripts like obfuscations and poetry.

Heck you should also do silly and/or childish things as often as you can. Life's more fun like that. But avoid karioke whereever possible.

____________________
Jeremy
I didn't believe in evil until I dated it.

Comment on Adult learning problem
(jeffa) Re: Adult learning problem
by jeffa (Chancellor) on Apr 05, 2002 at 06:24 UTC
    I recommend the book Code by Charles Petzold, but i really don't know how we could get Eiffel your flatmate (yep, i fell for it perrin) to read it. It's full of silly things like learning Braille and Morse Code, exploring number systems and logic, building half and full adders, a nice essay on the 8080 and 6800 microprocessors, ASCII, how RAM works, etc., etc., etc.

    This is one of those books you read away from the computer in a casual manner.

    jeffa

    you know i'll be coding silly stuff ;)
Re: Adult learning problem
by rjray (Chaplain) on Apr 05, 2002 at 07:24 UTC

    This is an "affliction" to which I often fall prey. It slowed me down when I was first learning Perl in the pre-4.0.19 days, and still gets in the way when I try to evaluate newer things for the sake of project planning.

    I know that one thing that regularly trips me up is when a book or tutorial use nonsensical examples, ones that the mind automatically dismisses. I get so tired of "Hello World", and SOAP or other web service technologies that seem to think the only application of web services ever is going to be fetching stock quotes. I've kept that in mind as I write the book I'm working on, trying to make the examples interesting enough to at least read once or twice. If the examples don't draw the attention in, then the reader may miss an important point or element. This could make things that much harder later on.

    There's a thought: a compendium of simple-but-useful exercises for people to use when learning new languages. Something like, "replicate the ls command, with at leaast n of the switches", as a means of drilling on the language's interface to the file-system related syscalls.

    --rjray

Re: Adult learning problem
by grinder (Bishop) on Apr 05, 2002 at 07:53 UTC
    He's going to fight to the last against doing something 'childish', even though I assure him that when I'm coding professionally I'm doing little test scripts more than I'm working on the 'real' program.

    Right on, jepri! I just had a quick scan on 4 different accounts here at work, that reveals some 400+ little test scripts. On each machine I have a ~/perl directory where I try out snippets to check how things work. For instance, the other day I had hesitations about how splice works, because I use it so rarely. So I whipped up "muncharr" which looks like:

    #! /usr/bin/perl -w use strict; my @arr = ('a'..'z'); my $nr = shift || 6; local $, = ' '; while( scalar @arr ) { my @block = splice( @arr, 0, $nr ); print "@block\n"; }

    With that, I was able to see straight away that my understanding of how splice worked was in line with reality. It took me about 2 minutes for take the time out to perldoc -f splice and test this out. I was then able to fold the principle back into my main code and safe in the knowledge that at least that part of the code was likely to be bug-free :)

    And I suppose it is useful to stress that even little snippets are deserving of strict and -w. Also note how I wrote the script to use default value(s) that can be overriden from the command line.


    print@_{sort keys %_},$/if%_=split//,'= & *a?b:e\f/h^h!j+n,o@o;r$s-t%t#u'

      A good way to get to know splice better is to re-implement push, pop, unshift and shift with it.
      A good way to get to know substr better is to create push/pop/unshift/shift functions for strings.

      Often, a good way to learn is re-inventing the wheel. I'd rather re-invent a wheel than greet the world.

      U28geW91IGNhbiBhbGwgcm90MTMgY
      W5kIHBhY2soKS4gQnV0IGRvIHlvdS
      ByZWNvZ25pc2UgQmFzZTY0IHdoZW4
      geW91IHNlZSBpdD8gIC0tIEp1ZXJk
      

        A good way to get to know splice better is to re-implement push, pop, unshift and shift with it.

        Uhm, or you could just read the docs :-)

        D:\Development>perldoc -f splice splice ARRAY,OFFSET,LENGTH,LIST ..... The following equivalences hold (assuming "$[ == 0"): push(@a,$x,$y) splice(@a,@a,0,$x,$y) pop(@a) splice(@a,-1) shift(@a) splice(@a,0,1) unshift(@a,$x,$y) splice(@a,0,0,$x,$y) $a[$x] = $y splice(@a,$x,1,$y)
        A good way to get to know substr better is to create push/pop/unshift/shift functions for strings.

        Well.... Once you know how to implement splice using susbtr you dont need to implement push/pop/unshift or shift, but its true it might be a good exercise. Personally would suggest taking that thought a step further and reimplement Tie::CharArray, by the time you are done if you dont understand Tie's, Array implementation, Splice Implementation and Substr implementation then I would say theres something very wrong... (either with the individual or the code ;-) Oh and it probably is a good idea because you can use the CPAN module for a proper code comparison and review afterward.

        Thats what I did to learn Tie the first time anyway... :-)

        Yves / DeMerphq
        ---
        Writing a good benchmark isnt as easy as it might look.

        That certainly seems to be the standard teaching method in the scheme and lisp worlds. The number of such books I've seen that have you recoding length and the like. And it seems to work.
      This is truly sage advice. I often resort to the 'test' script to fully flesh out a language construct that I don't fully understand or fully test an algorithm/idea that I'm working on.

      I find these 'test' scripts very useful. I'm glad that I'm not the only one doing this.

      metadoktor

      "The doktor is in."

Re: Adult learning problem
by rinceWind (Monsignor) on Apr 05, 2002 at 16:04 UTC
    jepri, the story about your flatmate Eiffel rang serious bells. In my 20 years IT career, I have encountered many examples of people with this attitude set. My advice to you is to be tougher on the individual, and encourage responsibility at the same time. Make it clear that it is his computer science course and his loss if he does not want to listen to your advice (this may appear patronising to someone observing, but this method works).

    I have had experience of training, mentoring and managing people in this category. There are several mistakes that are easy to make:

    • Doing the chap's grunt work for him. Apart from losing respect, this is damaging as it re-enforces his arrogance. The best way is to say "No: you do it - or find someone else to help".
    • Doing the chap's thinking for him. This is worse. This risks making him dependent on you for any cognitive processing required in problem solving.
    • Appearing unapproachable. This appears to countermand the other advice here, but if you make it clear that you are willing to listen to _reasonable_ requests, you will gain respect. A successful approach here is "what would YOU do to solve this problem".
    • Being too sparing on the praise when due. many people are quick to find fault, but timely praise reaps dividends. This may earn you pints of beer and lifelong friends.
    In terms of getting him to engage in the first place, it is worthwhile looking at the size of the problem he is working on, and whether this is too easy or hard. Get him to talk about what he feels about the problem. Apply project management theory, and encourage him to do the same. Break the task down into smaller units.

    Update: Interesting to see how I have miss-parsed the English phrase "teaching my flatmate Eiffel". Doh! - there was tiredness and lack of coffee creeping in, but I wonder how any future NLP bots would have coped with this one.

      Thankfully I did something similar to your advice (this is all in the past). He wanted to get me into the lab for the last nighter effort. I declined and he went by himself, made some friends who were in the same boat, and got most of the program done. So it sounds like he's getting into the culture a bit too.

      I suspect I am too sparing with the praise though.

      ____________________
      Jeremy
      I didn't believe in evil until I dated it.

Re: Adult learning problem
by perrin (Chancellor) on Apr 05, 2002 at 16:21 UTC
    It cracks me up that people on this thread seem to think that your roommate's name is Eiffel, rather than the programming language.

    Personally, I think the whole OO ball of wax is a little much for a beginner. I might start a new programmer with somethink easy like Basic or even... Perl. But he probably has no choice because it's for a class.

    One thing I've noticed over the years is that while programming is pretty easy, many people just don't like it, or lack the patience for it. I tell them if it's not fun, don't bother. There are already plenty of us who like it. ("The first rule of Perl Club is...")

Re: Adult learning problem
by seattlejohn (Deacon) on Apr 05, 2002 at 16:51 UTC
    Interesting comment. I think many people forget, or are simply not aware in the first place, of how much time it takes to achieve mastery -- or even competence! -- in almost anything.

    I marvel at how the human brain is able to take tasks that seem difficult and require huge amounts of attention at first, and internalize those with practice so that the mechanics of the task become unconscious, freeing us to focus on the more strategic issues. Unfortunately, that may give us the illusion that something is (or should be) "easy" if we're insufficiently introspective to remember what it felt like to be inexperienced in a particular domain.

    Driving a car is a skill most of us probably take for granted, and do often enough that it's become almost automatic, but it takes a lot of training and practice to acquire that skill in the first place. Or writing -- think how much time we spent as children learning the basics of how to hold the pencil and draw the simple letter A! (Or whatever the equivalent in one's native language might be.) Learning to ride a bike, to play a musical instrument, to speak and understand a new language, to dance, to solve mathematical problems, to play chess or poker, to build a house, and yes, to program a computer -- none of them just magically come to you, whether you're 10 years old or 50.

    I can imagine your frustration at watching your flatmate ignore this reality. I'm not sure how much you can do for him, though, if he's not willing to acknowledge that developing skills takes time and effort. I'm guessing that either he will discover that his approach is not fruitful and realize he needs to focus on the fundamentals, or -- sad but probably more likely -- decide that computer programming is not something he really wants to become proficient at after all.

    Update: The observation that your flatmate doesn't want to do something 'childish' got me thinking. Children are interesting, because although they lack a lot of skills and real-world knowledge acquired through experience, they have some traits that are particularly useful in acquiring those skills and real-world knowledge in the first place: They ask "why", they try new things (except vegetables ;-), they don't worry as much about how people will perceive them. Maybe being a little childish is not such a bad thing!

Re: Adult learning problem
by one4k4 (Hermit) on Apr 05, 2002 at 17:13 UTC
    On a semi-comical note, yet somewhat serious, I think we also fail to recognize exactly how many productionized pieces of code are simply join()'d pieces of test code.

    I don't really speak for anybody else, but I know I've seen places where production code is in fact littered with commented "test" blocks of code. imho its quite humor(ou|iou)s.

    _14k4 - perlmonks@poorheart.com (www.poorheart.com)
Re: Adult learning problem
by cowens (Beadle) on Apr 05, 2002 at 20:38 UTC
    <rant>
    I don't understand why people are against childish behavior. When do you learn the most in your life? When you are a child. Childish behavior is exploratory in nature. Sure childish behavior in social situations is not a good thing (you should know the rules about that by now and shouldn't have to actually throw that banana at your cow-orker to know what will happen). But, in situations where you don't know the rules yet, childish behavior is the smartest approach. One of the first things we learn to do is to play, and through playing we learn more about how things work. More adults should play.
    </rant>
Re: Adult learning problem
by trs80 (Priest) on Apr 05, 2002 at 23:47 UTC
    For someone to develop a style they have to be allowed to experiment, no matter how painful it is for the people that know how to do it "the right way". I go through this constantly with my children, I think they should "know" how to do something or they should do it the way I do, it is very hard to allow someone to grow at their own pace.

    By watching others learn you learn as well. You learn how they approach problems, this is very important if you are going to modify or correct a certain behavior/action. You need to first see it through their eyes instead yours before you can best advise them.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (10)
As of 2014-09-23 22:30 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (241 votes), past polls