Re: [Discuss] pulling along those behind

[Peter Steinbach]

For all those interested, I finished a first version of the blog post on 
the etherpad. Feel free to dial over and provide feedback or make 
additions. I'd then convert this to a PR to the SWC site repo.


Best,
Peter

On 10/28/2015 09:59 AM, Greg Wilson wrote:

Hi everyone,

The simplest way to start might be to throw stuff into this Etherpad:
http://pad.software-carpentry.org/pulling-along-those-behind

Cheers,
Greg

___
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org



--
Peter Steinbach, Dr. rer. nat.
HPC Developer, Scientific Computing Facility

Scionics Computer Innovation GmbH
Löscherstr. 16
01309 Dresden
Germany

phone +49 351 210 2882
fax   +49 351 202 707 04
www.scionics.de

Sitz der Gesellschaft: Dresden (Main office)
Amtsgericht - Registergericht: Dresden HRB 20337 (Commercial Registry)
Ust-IdNr.: DE813263791 (VAT ID Number)
Geschäftsführer: John Duperon, Jeff Oegema (Managing Directors)

___
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org

Re: [Discuss] pulling along those behind

[Karin Lagesen]

One of the things that I always emphasize before and during the workshop 
is that my aim is not to teach them to be programmers, but to make it 
less scary if and when they do decide to learn things more in depth. My 
main goal is to demystify programming. That way, it becomes less about 
understanding every detail and more about finding out that it is not as 
complicated as it looks. I think that by doing that, even if I do lose 
somebody on the little things, I manage to keep them with me on the 
bigger, more conceptual things, if that makes sense.


Karin


On 27/10/15 17:38, Bill Mills wrote:

I stretch the skill-level bracket of all my workshops by leaning heavily
on tiered challenge problems; I break for problems regularly (every 30
minutes or so, giving those really struggling a chance to catch up), and
set 'baseline' problems (that everyone is expected to solve) and
'stretch' goals - harder problems that the intermediates can derive
value from.

On Tue, Oct 27, 2015 at 9:33 AM, Noam Ross > wrote:

One thing that I've found is that students who are behind sometimes
give up trying to type along and just read along with the lesson
notes.  While it's not the ideal outcome, it may be the best one for
some fraction of students, and this makes it easier for those
students to reference those notes at some later time.  So it might
be worthwhile to point students to each lesson's notes before
starting that section.

On Tue, Oct 27, 2015 at 12:29 PM C. Titus Brown > wrote:

Hi Amanda et al.,

thanks, this is a nice discussion!

I try to distinguish between "zero entry" and more advanced
workshops
as clearly as possible, but of course problems happen in both
directions
for the advanced workshops - too advanced, and too beginner.

One strategy that (I think) Greg suggested a long time ago was
to suggest
that the too-advanced people help out with the too-beginner
people when
a TA wasn't available.  Of course this can go wrong as well, but
I think
when it goes well it's quite nice.

cheers,
--titus

On Tue, Oct 27, 2015 at 03:46:12PM +, Amanda Charbonneau wrote:
 > I actually had a similar problem, but with an intro workshop
that I had
 > already pared down considerably because I knew the learners
were skewed
 > towards *very* beginners. Even with the simplified material,
I had a
 > handful of people who couldn't keep up, people who had to
hover a single
 > finger back and forth over the keyboard to locate each letter.
 > This handful of people comprised about a quarter of the
attendees, and
 > the advertising clearly said that the course was for learners
who have
 > little to no prior computational experience, so they hadn't
really gone to
 > the wrong course level. It was just that their interpretation
of no prior
 > computational experience was very different from what SWC
expects. It felt
 > wrong to just press on without them, so I slowed everything
down to a
 > crawl, but I also felt extremely bad that we only got partway
through any
 > of the material.
 >
 > Sorry I don't have a solution, just commiseration.
 >
 > -amanda
 >
 > On Tue, Oct 27, 2015 at 11:24 AM Peter Steinbach
>
 > wrote:
 >
 > > Hi April,
 > >
 > > thanks for your insights. As a matter of fact, in my case
the local
 > > organizers were very forthcoming and implemented a
pre-assessment form
 > > before the workshop. Still, I had the feeling during the
workshop that
 > > this pre-assessment only covered the tip of the iceberg (as
expected).
 > >
 > > I guess the trade-off who to bore and whom to carry through
is always on
 > > the plate of the instructor. I'd have to say that being in
a team of 2
 > > helps at this point tremendously as the co-instructor is
among the
 > > "students" and simply can assist here and there.
 > >
 > > If people have more feedback on the matter, I am happy to
hear it. If
 > > not, my gratitude to those that replied already.
 > >
 > > Best,
 > > Peter
 > >
 > > On 10/27/2015 03:27 PM, April Wright wrote:
 > > > Hi Peter-
 > > >
 > > > I've been in this exact same situation, though with a
departmental
 > > > workshop, rather than an SWC one. It's hard, and I'm
sorry that 

Re: [Discuss] Report: Software Carpentry 2015-10-27-28

[Raniere Silva]

Hi Maxime,

thanks to share the information about the workshop.

> I think this is a very good ratio of "no show".

Agreed.

>  * Git bash, used on Windows to teach bash and git, does not contain
>nano, or any simple editor (but it contains vi... )
>  * Many users had trouble configuring another editor on Windows.
>Software Carpentry documents how to do it on their website, and we
>were not aware of it (a student pointed it to us).

We provide one installer that will install nano
that I thought was mention at the workshop template.

Cheers,
Raniere


signature.asc
Description: PGP signature
___
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org

Re: [Discuss] Report: Software Carpentry 2015-10-27-28

[Maxime Boissonneault]

Hi Raniere,
Indeed, this was pointed out by my collegue, but it had eluded me. I 
will have to check again for the workshop I am giving in 2 weeks.


Thanks,

Maxime

Le 2015-10-28 22:06, Raniere Silva a écrit :

Hi Maxime,

thanks to share the information about the workshop.


I think this is a very good ratio of "no show".

Agreed.


  * Git bash, used on Windows to teach bash and git, does not contain
nano, or any simple editor (but it contains vi... )
  * Many users had trouble configuring another editor on Windows.
Software Carpentry documents how to do it on their website, and we
were not aware of it (a student pointed it to us).

We provide one installer that will install nano
that I thought was mention at the workshop template.

Cheers,
Raniere



--
-
Maxime Boissonneault
Analyste de calcul - Calcul Québec, Université Laval
Instructeur Software Carpentry
Président - Comité de coordination du soutien à la recherche de Calcul Québec
Ph. D. en physique


___
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org

Re: [Discuss] pulling along those behind

[Karin Lagesen]

+1000 to this.

On that note, I always congratulate people when they get their first 
error message. Only way to learn is to fail first.


Karin

On 28/10/15 21:49, Sam Penrose wrote:

I wonder if it is helpful in effect to reverse the polarity of the
identification, to say:

Programmers spend their time getting complex systems to play nicely,
which is a process of repeatedly getting stuck, then making some
progress, then getting stuck again. If you have felt stuck or
bewildered at any point this morning, you were at that very moment
programming. You are a programmer because you have already done what
professional programmers do. Of course, we all try to work efficiently
and make progress. You don't drive a Jeep for the purpose of breaking
down in the back country, but we all recognize that the occasional
breakdown is part of the journey. When you are sitting next to your
Jeep and the big rock that broke its axle, you're not some phony
armchair traveller in your living room. Even if its your first trip,
you are a traveller. You are in the back country, with bugs and mud
and, hopefully, beauty and accomplishment. When the message from the
installer makes no sense at all, you're not a fraud. You are
programming. So get help or make do, but don't feel like an impostor
or a failure. You are a programmer doing your work, and you deserve
respect for that -- especially from yourself.

On Wed, Oct 28, 2015 at 1:24 PM, David Martin (Staff)
 wrote:

What Karin says.

Even in a less pressured environment there is no hope of someone turning up to 
a SC workshop and coming out of it a fully functioning and competent person int 
he areas they have been exposed to. However, what we have done, as instructors, 
is to sketch the route map and show how the concepts link together. The best 
students will spend 3x longer than the contact hours going back over it and 
learning the material thoroughly as they apply it.

..d

Dr David Martin
Lecturer in Bioinformatics
College of Life Sciences
University of Dundee



From: Discuss  on behalf of Karin 
Lagesen 
Sent: 28 October 2015 20:11
To: discuss@lists.software-carpentry.org
Subject: Re: [Discuss] pulling along those behind

One of the things that I always emphasize before and during the workshop
is that my aim is not to teach them to be programmers, but to make it
less scary if and when they do decide to learn things more in depth. My
main goal is to demystify programming. That way, it becomes less about
understanding every detail and more about finding out that it is not as
complicated as it looks. I think that by doing that, even if I do lose
somebody on the little things, I manage to keep them with me on the
bigger, more conceptual things, if that makes sense.

Karin


On 27/10/15 17:38, Bill Mills wrote:

I stretch the skill-level bracket of all my workshops by leaning heavily
on tiered challenge problems; I break for problems regularly (every 30
minutes or so, giving those really struggling a chance to catch up), and
set 'baseline' problems (that everyone is expected to solve) and
'stretch' goals - harder problems that the intermediates can derive
value from.

On Tue, Oct 27, 2015 at 9:33 AM, Noam Ross > wrote:

 One thing that I've found is that students who are behind sometimes
 give up trying to type along and just read along with the lesson
 notes.  While it's not the ideal outcome, it may be the best one for
 some fraction of students, and this makes it easier for those
 students to reference those notes at some later time.  So it might
 be worthwhile to point students to each lesson's notes before
 starting that section.

 On Tue, Oct 27, 2015 at 12:29 PM C. Titus Brown > wrote:

 Hi Amanda et al.,

 thanks, this is a nice discussion!

 I try to distinguish between "zero entry" and more advanced
 workshops
 as clearly as possible, but of course problems happen in both
 directions
 for the advanced workshops - too advanced, and too beginner.

 One strategy that (I think) Greg suggested a long time ago was
 to suggest
 that the too-advanced people help out with the too-beginner
 people when
 a TA wasn't available.  Of course this can go wrong as well, but
 I think
 when it goes well it's quite nice.

 cheers,
 --titus

 On Tue, Oct 27, 2015 at 03:46:12PM +, Amanda Charbonneau wrote:
  > I actually had a similar problem, but with an intro workshop
 that I had
  > already pared down considerably because I knew the learners
 were skewed
  > towards *very* beginners. Even with the simplified material,
 I had a

Re: [Discuss] pulling along those behind

[Sam Penrose]

I wonder if it is helpful in effect to reverse the polarity of the
identification, to say:

Programmers spend their time getting complex systems to play nicely,
which is a process of repeatedly getting stuck, then making some
progress, then getting stuck again. If you have felt stuck or
bewildered at any point this morning, you were at that very moment
programming. You are a programmer because you have already done what
professional programmers do. Of course, we all try to work efficiently
and make progress. You don't drive a Jeep for the purpose of breaking
down in the back country, but we all recognize that the occasional
breakdown is part of the journey. When you are sitting next to your
Jeep and the big rock that broke its axle, you're not some phony
armchair traveller in your living room. Even if its your first trip,
you are a traveller. You are in the back country, with bugs and mud
and, hopefully, beauty and accomplishment. When the message from the
installer makes no sense at all, you're not a fraud. You are
programming. So get help or make do, but don't feel like an impostor
or a failure. You are a programmer doing your work, and you deserve
respect for that -- especially from yourself.

On Wed, Oct 28, 2015 at 1:24 PM, David Martin (Staff)
 wrote:
> What Karin says.
>
> Even in a less pressured environment there is no hope of someone turning up 
> to a SC workshop and coming out of it a fully functioning and competent 
> person int he areas they have been exposed to. However, what we have done, as 
> instructors, is to sketch the route map and show how the concepts link 
> together. The best students will spend 3x longer than the contact hours going 
> back over it and learning the material thoroughly as they apply it.
>
> ..d
>
> Dr David Martin
> Lecturer in Bioinformatics
> College of Life Sciences
> University of Dundee
>
>
> 
> From: Discuss  on behalf of 
> Karin Lagesen 
> Sent: 28 October 2015 20:11
> To: discuss@lists.software-carpentry.org
> Subject: Re: [Discuss] pulling along those behind
>
> One of the things that I always emphasize before and during the workshop
> is that my aim is not to teach them to be programmers, but to make it
> less scary if and when they do decide to learn things more in depth. My
> main goal is to demystify programming. That way, it becomes less about
> understanding every detail and more about finding out that it is not as
> complicated as it looks. I think that by doing that, even if I do lose
> somebody on the little things, I manage to keep them with me on the
> bigger, more conceptual things, if that makes sense.
>
> Karin
>
>
> On 27/10/15 17:38, Bill Mills wrote:
>> I stretch the skill-level bracket of all my workshops by leaning heavily
>> on tiered challenge problems; I break for problems regularly (every 30
>> minutes or so, giving those really struggling a chance to catch up), and
>> set 'baseline' problems (that everyone is expected to solve) and
>> 'stretch' goals - harder problems that the intermediates can derive
>> value from.
>>
>> On Tue, Oct 27, 2015 at 9:33 AM, Noam Ross > > wrote:
>>
>> One thing that I've found is that students who are behind sometimes
>> give up trying to type along and just read along with the lesson
>> notes.  While it's not the ideal outcome, it may be the best one for
>> some fraction of students, and this makes it easier for those
>> students to reference those notes at some later time.  So it might
>> be worthwhile to point students to each lesson's notes before
>> starting that section.
>>
>> On Tue, Oct 27, 2015 at 12:29 PM C. Titus Brown > > wrote:
>>
>> Hi Amanda et al.,
>>
>> thanks, this is a nice discussion!
>>
>> I try to distinguish between "zero entry" and more advanced
>> workshops
>> as clearly as possible, but of course problems happen in both
>> directions
>> for the advanced workshops - too advanced, and too beginner.
>>
>> One strategy that (I think) Greg suggested a long time ago was
>> to suggest
>> that the too-advanced people help out with the too-beginner
>> people when
>> a TA wasn't available.  Of course this can go wrong as well, but
>> I think
>> when it goes well it's quite nice.
>>
>> cheers,
>> --titus
>>
>> On Tue, Oct 27, 2015 at 03:46:12PM +, Amanda Charbonneau wrote:
>>  > I actually had a similar problem, but with an intro workshop
>> that I had
>>  > already pared down considerably because I knew the learners
>> were skewed
>>  > towards *very* beginners. Even with the simplified material,
>> I had a
>>  > handful of 

Re: [Discuss] pulling along those behind

[David Martin (Staff)]

What Karin says.

Even in a less pressured environment there is no hope of someone turning up to 
a SC workshop and coming out of it a fully functioning and competent person int 
he areas they have been exposed to. However, what we have done, as instructors, 
is to sketch the route map and show how the concepts link together. The best 
students will spend 3x longer than the contact hours going back over it and 
learning the material thoroughly as they apply it.

..d

Dr David Martin
Lecturer in Bioinformatics
College of Life Sciences
University of Dundee



From: Discuss  on behalf of Karin 
Lagesen 
Sent: 28 October 2015 20:11
To: discuss@lists.software-carpentry.org
Subject: Re: [Discuss] pulling along those behind

One of the things that I always emphasize before and during the workshop
is that my aim is not to teach them to be programmers, but to make it
less scary if and when they do decide to learn things more in depth. My
main goal is to demystify programming. That way, it becomes less about
understanding every detail and more about finding out that it is not as
complicated as it looks. I think that by doing that, even if I do lose
somebody on the little things, I manage to keep them with me on the
bigger, more conceptual things, if that makes sense.

Karin


On 27/10/15 17:38, Bill Mills wrote:
> I stretch the skill-level bracket of all my workshops by leaning heavily
> on tiered challenge problems; I break for problems regularly (every 30
> minutes or so, giving those really struggling a chance to catch up), and
> set 'baseline' problems (that everyone is expected to solve) and
> 'stretch' goals - harder problems that the intermediates can derive
> value from.
>
> On Tue, Oct 27, 2015 at 9:33 AM, Noam Ross  > wrote:
>
> One thing that I've found is that students who are behind sometimes
> give up trying to type along and just read along with the lesson
> notes.  While it's not the ideal outcome, it may be the best one for
> some fraction of students, and this makes it easier for those
> students to reference those notes at some later time.  So it might
> be worthwhile to point students to each lesson's notes before
> starting that section.
>
> On Tue, Oct 27, 2015 at 12:29 PM C. Titus Brown  > wrote:
>
> Hi Amanda et al.,
>
> thanks, this is a nice discussion!
>
> I try to distinguish between "zero entry" and more advanced
> workshops
> as clearly as possible, but of course problems happen in both
> directions
> for the advanced workshops - too advanced, and too beginner.
>
> One strategy that (I think) Greg suggested a long time ago was
> to suggest
> that the too-advanced people help out with the too-beginner
> people when
> a TA wasn't available.  Of course this can go wrong as well, but
> I think
> when it goes well it's quite nice.
>
> cheers,
> --titus
>
> On Tue, Oct 27, 2015 at 03:46:12PM +, Amanda Charbonneau wrote:
>  > I actually had a similar problem, but with an intro workshop
> that I had
>  > already pared down considerably because I knew the learners
> were skewed
>  > towards *very* beginners. Even with the simplified material,
> I had a
>  > handful of people who couldn't keep up, people who had to
> hover a single
>  > finger back and forth over the keyboard to locate each letter.
>  > This handful of people comprised about a quarter of the
> attendees, and
>  > the advertising clearly said that the course was for learners
> who have
>  > little to no prior computational experience, so they hadn't
> really gone to
>  > the wrong course level. It was just that their interpretation
> of no prior
>  > computational experience was very different from what SWC
> expects. It felt
>  > wrong to just press on without them, so I slowed everything
> down to a
>  > crawl, but I also felt extremely bad that we only got partway
> through any
>  > of the material.
>  >
>  > Sorry I don't have a solution, just commiseration.
>  >
>  > -amanda
>  >
>  > On Tue, Oct 27, 2015 at 11:24 AM Peter Steinbach
> >
>  > wrote:
>  >
>  > > Hi April,
>  > >
>  > > thanks for your insights. As a matter of fact, in my case
> the local
>  > > organizers were very forthcoming and implemented a
> pre-assessment form
>  > > before the workshop. Still, I had the 

Re: [Discuss] pulling along those behind

[David Martin (Staff)]

I encourage the students to break it in a known way so they can recognise the 
error messages. 'What happens if you forget to close the quote/miss out the 
comma' etc. Now you know what error you get so you know what to look for if you 
see that error again (unclosed quote/missing comma etc.)

If you are not failing some of the time then you are not trying hard enough 
problems. If you are not succeeding some of the time then the problems are too 
hard.

..d

Dr David Martin
Lecturer in Bioinformatics
College of Life Sciences
University of Dundee



From: Karin Lagesen 
Sent: 28 October 2015 20:54
To: Sam Penrose; David Martin (Staff)
Cc: discuss@lists.software-carpentry.org
Subject: Re: [Discuss] pulling along those behind

+1000 to this.

On that note, I always congratulate people when they get their first
error message. Only way to learn is to fail first.

Karin

On 28/10/15 21:49, Sam Penrose wrote:
> I wonder if it is helpful in effect to reverse the polarity of the
> identification, to say:
>
> Programmers spend their time getting complex systems to play nicely,
> which is a process of repeatedly getting stuck, then making some
> progress, then getting stuck again. If you have felt stuck or
> bewildered at any point this morning, you were at that very moment
> programming. You are a programmer because you have already done what
> professional programmers do. Of course, we all try to work efficiently
> and make progress. You don't drive a Jeep for the purpose of breaking
> down in the back country, but we all recognize that the occasional
> breakdown is part of the journey. When you are sitting next to your
> Jeep and the big rock that broke its axle, you're not some phony
> armchair traveller in your living room. Even if its your first trip,
> you are a traveller. You are in the back country, with bugs and mud
> and, hopefully, beauty and accomplishment. When the message from the
> installer makes no sense at all, you're not a fraud. You are
> programming. So get help or make do, but don't feel like an impostor
> or a failure. You are a programmer doing your work, and you deserve
> respect for that -- especially from yourself.
>
> On Wed, Oct 28, 2015 at 1:24 PM, David Martin (Staff)
>  wrote:
>> What Karin says.
>>
>> Even in a less pressured environment there is no hope of someone turning up 
>> to a SC workshop and coming out of it a fully functioning and competent 
>> person int he areas they have been exposed to. However, what we have done, 
>> as instructors, is to sketch the route map and show how the concepts link 
>> together. The best students will spend 3x longer than the contact hours 
>> going back over it and learning the material thoroughly as they apply it.
>>
>> ..d
>>
>> Dr David Martin
>> Lecturer in Bioinformatics
>> College of Life Sciences
>> University of Dundee
>>
>>
>> 
>> From: Discuss  on behalf of 
>> Karin Lagesen 
>> Sent: 28 October 2015 20:11
>> To: discuss@lists.software-carpentry.org
>> Subject: Re: [Discuss] pulling along those behind
>>
>> One of the things that I always emphasize before and during the workshop
>> is that my aim is not to teach them to be programmers, but to make it
>> less scary if and when they do decide to learn things more in depth. My
>> main goal is to demystify programming. That way, it becomes less about
>> understanding every detail and more about finding out that it is not as
>> complicated as it looks. I think that by doing that, even if I do lose
>> somebody on the little things, I manage to keep them with me on the
>> bigger, more conceptual things, if that makes sense.
>>
>> Karin
>>
>>
>> On 27/10/15 17:38, Bill Mills wrote:
>>> I stretch the skill-level bracket of all my workshops by leaning heavily
>>> on tiered challenge problems; I break for problems regularly (every 30
>>> minutes or so, giving those really struggling a chance to catch up), and
>>> set 'baseline' problems (that everyone is expected to solve) and
>>> 'stretch' goals - harder problems that the intermediates can derive
>>> value from.
>>>
>>> On Tue, Oct 27, 2015 at 9:33 AM, Noam Ross >> > wrote:
>>>
>>>  One thing that I've found is that students who are behind sometimes
>>>  give up trying to type along and just read along with the lesson
>>>  notes.  While it's not the ideal outcome, it may be the best one for
>>>  some fraction of students, and this makes it easier for those
>>>  students to reference those notes at some later time.  So it might
>>>  be worthwhile to point students to each lesson's notes before
>>>  starting that section.
>>>
>>>  On Tue, Oct 27, 2015 at 12:29 PM C. Titus Brown >>  > wrote:
>>>
>>>  Hi 

Re: [Discuss] pulling along those behind

[Greg Wilson]

Hi everyone,

The simplest way to start might be to throw stuff into this Etherpad: 
http://pad.software-carpentry.org/pulling-along-those-behind


Cheers,
Greg

___
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org