Bennet, I like the idea of building up on an example. At the very end of our workshop, after Git, we still had about an hour left over so I revisited the python material with a worked example. I had a FASTA formatted set of protein sequences in the data folder I had the class clone earlier in the day, and we wrote a program that pulled out all of the sequence IDs. This basically used all the core concepts we had learned in the python lessons: Functions, loops, conditionals, lists, slicing strings... It also gave me an excuse to introduce a little bit of file handling (using the 'with' syntax to open a file, and then looping over the handle). It might be pretty easy to pitch this as a problem at the outset, and then build it up piece-by-piece as the workshop progresses (at least for a life sciences audience). Tough example to feed into pandas or matplotlib though...
-Steve On 10/20/16, 11:01 AM, "Bennet Fauber" <[email protected]> wrote: >Lex, > >Yes, I have. I try to always do that (when there is a cool >application to be aimed at). I consider that to be part of the >'abstract' or the 'roadmap' given at the beginning of the lesson, >where I say, this is what we want to do, we're going to break the >problem into pieces, and we'll work on smaller pieces till they work, >and then we'll chain them together. That's kind of how real work >goes, too, at least in my experience. > >Anecdotal evidence from my experience suggests that starting with the >nice logical development without some sort of project to aim for >reminds people of all the things they disliked and feared about >'traditionally' taught math courses. It also doesn't reflect how >people in the field approach problems. I think starting with some >plausible, explained task, breaking it down, solving pieces, and >gluing them back together is a better simulation of their future >activities. > >Short-term memory and lack of fluency are powerful enemies to the >logical approach. People often seem not to be able to absorb and >internalize the details sufficiently to have them at hand and ready >several hours later when they are used to stitch things together. >That has been my experience from both sides of the lectern. > >Providing small programs that are part of a large puzzle, each of >which has some recognizable function, and slipping in technical >details, seems to me to be better mirror of the cognitive absorption >patterns of people who are beginning. I try to make each of the >subprojects coolish -- something that runs and accomplishes something >useful -- as that helps morale and, well, accomplishes something. > >It needs to be carefully done -- feature creep on the final project >will kill this -- and it's better to do less more thoroughly. >Presenting the final project as part of the advert for the workshop, >possibly along with the steps from start to finish, may also be an >effective tool to enable potential participants to self-place. I've >had a couple of broken attempts, but mostly from trying to do too much >not too little. > >-- bennnet > > > > >On Thu, Oct 20, 2016 at 10:17 AM, Lex Nederbragt ><[email protected]> wrote: >> Hi, >> >> I have yet to make up my mind whether I prefer/believe more in the >> ¹show some cool, applicable, but perhaps confusing thing as early as >>possible to hook in learners¹ versus Œcarefully introduce programming >>concepts as usual and work towards the cool, applicable thing¹. But, has >>anyone tried to only demo 'the cool thing¹ at the very beginning, just >>showing how few lines of code it would take, and motivating the lesson >>with that this is (part of) what participants will have learned at the >>end? >> >> Lex >> >>> On 18 Oct 2016, at 15:50, Bond, Steve (NIH/NHGRI) [F] >>><[email protected]> wrote: >>> >>> Hi all, >>> Just by way of rational, we were hesitant to get into pandas and >>> matplotlib before introducing lists. By giving the students some time >>>to >>> absorb slicing syntax on simple data, the hope was that they would run >>> into less confusion when faced with a dataframe. As Greg says, we opted >>> for the bottom-up progression to try and minimize confusion instead of >>> diving right into the meat. Unfortunately we have not tried the other >>> order, so can't do a side-by-side comparison. I am, however, very >>>pleased >>> with how the workshop progressed. >>> Thanks to Greg, and everyone else involved, for putting together such >>>an >>> awesome resource. >>> -Steve >>> >>> >>> On 10/18/16, 6:43 AM, "Greg Wilson" <[email protected]> >>> wrote: >>> >>>> Hi everyone, >>>> >>>> Steve Bond and John Didion used the new "intro to Python for data >>>> analysis using Gapminder data" lesson at NIH recently; as well as >>>> filling in a bunch of exercises (thanks!), they rearranged the order >>>>of >>>> the episodes - you can see their version at >>>> https://biologyguy.github.io/python-novice-gapminder/. I've opened an >>>> issue at >>>> https://github.com/swcarpentry/python-novice-gapminder/issues/113 to >>>> discuss whether their order makes more sense than the original: on the >>>> one hand, it's a more logical bottom-up progression, but on the other, >>>> it means that the data analysis stuff takes longer to get to. Please >>>> add your comments to the issue: should we stick to the existing order, >>>> or use the NIH's? >>>> >>>> Thanks to John and Steve, and thanks in advance for your feedback, >>>> >>>> Greg >>>> >>>> >>>> -- >>>> Dr Greg Wilson >>>> Director of Instructor Training >>>> Software Carpentry Foundation >>>> >>>> _______________________________________________ >>>> Discuss mailing list >>>> [email protected] >>>> http://lists.software-carpentry.org/listinfo/discuss >>> >>> _______________________________________________ >>> Discuss mailing list >>> [email protected] >>> http://lists.software-carpentry.org/listinfo/discuss >> >> _______________________________________________ >> Discuss mailing list >> [email protected] >> http://lists.software-carpentry.org/listinfo/discuss >_______________________________________________ >Discuss mailing list >[email protected] >http://lists.software-carpentry.org/listinfo/discuss _______________________________________________ Discuss mailing list [email protected] http://lists.software-carpentry.org/listinfo/discuss
