Thanks, Bennet, inspiring! I should try this approach the next time I teach the
python module.
Lex
> On 20 Oct 2016, at 17:01, Bennet Fauber <ben...@umich.edu> 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
> <lex.nederbr...@ibv.uio.no> 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] <steve.b...@nih.gov>
>>> 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" <gvwil...@software-carpentry.org>
>>> 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
>>>> Discuss@lists.software-carpentry.org
>>>> http://lists.software-carpentry.org/listinfo/discuss
>>>
>>> _______________________________________________
>>> Discuss mailing list
>>> Discuss@lists.software-carpentry.org
>>> http://lists.software-carpentry.org/listinfo/discuss
>>
>> _______________________________________________
>> Discuss mailing list
>> Discuss@lists.software-carpentry.org
>> http://lists.software-carpentry.org/listinfo/discuss
> _______________________________________________
> Discuss mailing list
> Discuss@lists.software-carpentry.org
> http://lists.software-carpentry.org/listinfo/discuss
_______________________________________________
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/listinfo/discuss
