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
