subject:"\[Discuss\] pulling along those behind"

Re: [Discuss] pulling along those behind

2015-10-30 Thread Lex Nederbragt


> On 28 Oct 2015, at 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.


This is beautiful... I may quote that at the next workshop I’m teaching.

Lex


___
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

2015-10-30 Thread Greg Wilson


On 2015-10-30 5:14 PM, Steve Haddock wrote:

...I think people are so desperate for training that it would be hard to 
convince them *not* to sign up for an upcoming workshop even if it is not a 
perfect fit. If there is no fixed date for the hypothetical future workshop, 
they would not want to wait. So scheduling them in pairs at high-demand 
locations could help slot students where they properly belong.


I strongly agree, which is why I think we need a better pre-assessment 
tool to figure out who belongs in which workshop so we can steer people 
in the right direction.  If anyone knows faculty in education 
specializing in assessment who have grad students looking for really 
cool, useful, and publishable projects, please point 'em my way...


Thanks,
Greg

___
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

2015-10-30 Thread Steve Haddock


I think this thread is diverging from the important original topic: how to 
solve the problem of beginners in an intermediate class, or more broadly, the 
disparity between experience levels in any given class. 

Regarding that subject, I think people are so desperate for training that it 
would be hard to convince them *not* to sign up for an upcoming workshop even 
if it is not a perfect fit. If there is no fixed date for the hypothetical 
future workshop, they would not want to wait. So scheduling them in pairs at 
high-demand locations could help slot students where they properly belong. 

-Steve
___
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

2015-10-29 Thread Tyler Smith

On Thu, Oct 29, 2015, at 02:28 PM, Karin Lagesen wrote:
> 
> ...is there some statistics on this? I think that errors would be a lot 
> less scary if we could show how much of their time even those that code 
> for a living spend on debugging their code.
> 

Poking around on programmers.stackexchange, 50% shows up as a common
estimate of how much 'programming' effort is actually directed at
debugging. That actually seems low to me: I can generate bugs way faster
than I can find them!

http://programmers.stackexchange.com/a/91764/60644

___
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

2015-10-29 Thread Karin Lagesen


On 10/29/2015 7:40 AM, Matthew Gidden wrote:

A big +1 for explicitly introducing failure during the learning process.
I recently taught a course for people brand new to programming. There
were some explicit failures I added to some lessons, and I still
underestimated just how uncomfortable they would be with (even simple)
error messages.


...is there some statistics on this? I think that errors would be a lot 
less scary if we could show how much of their time even those that code 
for a living spend on debugging their code.


Karin


___
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

2015-10-28 Thread 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

2015-10-28 Thread 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] pulling along those behind

2015-10-28 Thread 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)
<d.m.a.mar...@dundee.ac.uk> 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 <discuss-boun...@lists.software-carpentry.org> on behalf of Karin 
Lagesen <karin.lage...@gmail.com>
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 <noam.r...@gmail.com
<mailto:noam.r...@gmail.com>> 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 <ctbr...@ucdavis.edu
 <mailto:ctbr...@ucdavis.edu>> 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*

Re: [Discuss] pulling along those behind

2015-10-28 Thread 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)
<d.m.a.mar...@dundee.ac.uk> 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 <discuss-boun...@lists.software-carpentry.org> on behalf of 
> Karin Lagesen <karin.lage...@gmail.com>
> 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 <noam.r...@gmail.com
>> <mailto:noam.r...@gmail.com>> 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 <ctbr...@ucdavis.edu
>> <mailto:ctbr...@ucdavis.edu>> 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,
>>

Re: [Discuss] pulling along those behind

2015-10-28 Thread 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 <discuss-boun...@lists.software-carpentry.org> on behalf of Karin 
Lagesen <karin.lage...@gmail.com>
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 <noam.r...@gmail.com
> <mailto:noam.r...@gmail.com>> 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 <ctbr...@ucdavis.edu
> <mailto:ctbr...@ucdavis.edu>> 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
> <steinb...@scionics.de <mailto:ste

Re: [Discuss] pulling along those behind

2015-10-28 Thread 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 <karin.lage...@gmail.com>
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)
> <d.m.a.mar...@dundee.ac.uk> 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 <discuss-boun...@lists.software-carpentry.org> on behalf of 
>> Karin Lagesen <karin.lage...@gmail.com>
>> 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 <noam.r...@gmail.com
>>> <mailto:noam.r...@gmail.com>> 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

Re: [Discuss] pulling along those behind

2015-10-28 Thread 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

[Discuss] pulling along those behind

2015-10-27 Thread Peter Steinbach


Hi to all,

I just taught a SWC workshop for intermediates. As usual, a considerable 
portion of the audience would have been better off attending a novice 
course first. This time the ratio was quite high though: 30-40% out of 
25 IIRC.


My question is simple, how do other instructors deal with this 
situation? We had 2-3 helpers that jumped in and stood at the side of 
those completely lost. But me, the instructor, I need to adapt 
accordingly ... I simply took many detours and tried to explain more 
what I was doing ... which might have lead to more confusion than it 
should have.


What method do you guys use here?

Best,
Peter

___
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

2015-10-27 Thread Mario Antonioletti



Hi,
   Mike Jackson here developed a set of scripts that capture the 
history of your bash screen and publishes it on a web site so that 
students/helpers have a chance to see what they missed while resolving 
a problem and now has scrolled off the screen. It's not ideal but it

does provide students with a chance of recapping what they missed. I
have not used the scripts but it is something to consider.

You can do what you do and give even more detail or more anecdotes or 
take more pauses, making sure that there are no red postit notes 
flagging issues. Whatever strategy one takes it's going to annoy 
someone so I am not sure there is a single answer to your question.


Mario

On Tue, 27 Oct 2015, Peter Steinbach wrote:


Hi to all,

I just taught a SWC workshop for intermediates. As usual, a considerable 
portion of the audience would have been better off attending a novice course 
first. This time the ratio was quite high though: 30-40% out of 25 IIRC.


My question is simple, how do other instructors deal with this situation? We 
had 2-3 helpers that jumped in and stood at the side of those completely 
lost. But me, the instructor, I need to adapt accordingly ... I simply took 
many detours and tried to explain more what I was doing ... which might have 
lead to more confusion than it should have.


What method do you guys use here?

Best,
Peter

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




+---+
|Mario Antonioletti:EPCC,JCMB,The King's Buildings,Edinburgh EH9 3FD.   |
|Tel:0131 650 5141|ma...@epcc.ed.ac.uk|http://www2.epcc.ed.ac.uk/~mario |
+---+
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


___
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

2015-10-27 Thread Raniere Silva

Hi Peter,

> Could you share these scripts?

Please check
https://github.com/swcarpentry/site/pull/1124/files#diff-9e17f2fd404c84648654a4fc54a9a2ecR71
 .
We are going to publish it this week.

> I'd like to see if they'd capture a nano screen etc
> (I presume not, but I'd like to try them anyhow).
> Apologies if they were already shared with this community and I overlooked 
> them.

There are terminal screen recorder that can capture nano
but from my experience they don't work for what you want. =(

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] pulling along those behind

2015-10-27 Thread Michael J Jackson

Hi Peter,

If there are more people falling behind than you have helpers to
handle, then I'd just slow down. I'd (reluctantly) rather bore those
who don't want a slower pace, than confuse those do.

cheers,
mike

Quoting Peter Steinbach on Tue, 27 Oct 2015
11:39:01 +0100:

Hi Raniere et al,

thanks for the pointers for recording the terminal history, I'd like
to get back to my more general question though ... how to give
participants that are not up to the level of the course a chance to
follow? I don't wanna drag them all through, at some point there has
to be a limit for the sake of the remaining crowd. But still, I'd
like to hear people's experience on this.

Best,
Peter

On 10/27/2015 11:23 AM, Raniere Silva wrote:

Hi Peter,

Could you share these scripts?

Please check
https://github.com/swcarpentry/site/pull/1124/files#diff-9e17f2fd404c84648654a4fc54a9a2ecR71
.

We are going to publish it this week.

I'd like to see if they'd capture a nano screen etc
(I presume not, but I'd like to try them anyhow).
Apologies if they were already shared with this community and I
overlooked them.

There are terminal screen recorder that can capture nano
but from my experience they don't work for what you want. =(

Cheers,
Raniere

--
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

Dr. Michael (Mike) Jackson m.jack...@epcc.ed.ac.uk
Software Architect Tel: +44 (0)131 650 5141
EPCC, The University of Edinburgh http://www.epcc.ed.ac.uk
Software Sustainability Institute http://www.software.ac.uk

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

___
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

2015-10-27 Thread Peter Steinbach

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 happened to
you.

Since you're SWC, I think the first thing to do is ask the host. Often, the
host has some specific ideas about what they want the learners to come away
with, and that can help you steer the course.

What I did, in practice, was this: I spent way too much time helping
novices. I slowed down, got through less than half of the material, and the
intermediates, who had actually chosen the correct class and paid a nominal
fee for it were very unsatisfied. I really think that I made the wrong call
by punishing people who carefully read the sign-up and prioritizing those
who didn't. There are a lot of resources out there to help people take the
first steps in programming. There are fewer to help with the 'what's next',
and I should have been more sensitive to that fact. What I should have done
is told people who were working on novice-level skills that they were
welcome to stay and work, but that people working on the course material
would be assisted first.

On the next go around, I added a list of skills the learners needed to be
comfortable with to attend (previously, it had simply been a link to the
previous workshop) and a code snippet one of the students had written. I
let them know that this was the level of familiarity they needed to have *with
Python* to attend, and that TAs would preferentially assist those who were
mastering course skills over those who were mastering other material.

That worked, I only had one person for whom the course was inappropriate
(they were too high level) show up.

--a

-
Postdoctoral Researcher
Iowa State University, EEOB
University of Kansas, EEB
251 Bessey Hall
Ames, IA 50011
512.940.5761
http://wrightaprilm.github.io/

On Tue, Oct 27, 2015 at 8:23 AM, Michael J Jackson
wrote:

Hi Peter,

If there are more people falling behind than you have helpers to handle,
then I'd just slow down. I'd (reluctantly) rather bore those who don't want
a slower pace, than confuse those do.

cheers,
mike

Quoting Peter Steinbach on Tue, 27 Oct 2015
11:39:01 +0100:

Hi Raniere et al,

thanks for the pointers for recording the terminal history, I'd like to
get back to my more general question though ... how to give participants
that are not up to the level of the course a chance to follow? I don't
wanna drag them all through, at some point there has to be a limit for the
sake of the remaining crowd. But still, I'd like to hear people's
experience on this.

Best,
Peter

On 10/27/2015 11:23 AM, Raniere Silva wrote:

Hi Peter,

Could you share these scripts?

Please check

https://github.com/swcarpentry/site/pull/1124/files#diff-9e17f2fd404c84648654a4fc54a9a2ecR71
.
We are going to publish it this week.

I'd like to see if they'd capture a nano screen etc

(I presume not, but I'd like to try them anyhow).
Apologies if they were already shared with this community and I
overlooked them.

There are terminal screen recorder that can capture nano
but from my experience they don't work for what you want. =(

Cheers,
Raniere

--
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

___
Discuss mailing list
Discuss@lists.software-carpentry.org

http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org

--
The University of Edinburgh is a charitable

Re: [Discuss] pulling along those behind

2015-10-27 Thread David Jones

On 27 October 2015 at 16:27, 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.

I was going to suggest that too. It's worth stressing to the
too-advanced people who have not tried this before that they will
learn plenty themselves by doing this, and it will be fun!

drj

___
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

2015-10-27 Thread Bill Mills

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
>> happened
>> > > to
>> > > > you.
>> > > >
>> > > > Since you're SWC, I think the first thing to do is ask the host.
>> Often,
>> > > the
>> > > > host has some specific ideas about what they want the learners to
>> come
>> > > away
>> > > > with, and that can help you steer the course.
>> > > >
>> > > > What I did, in practice, was this: I spent way too much time helping
>> > > > novices. I slowed down, got through less than half of the material,
>> and
>> > > the
>> > > > intermediates, who had actually chosen the correct class and paid a
>> > > nominal
>> > > > fee for it were very unsatisfied. I really think that I made the
>> wrong
>> > > call
>> > > > by punishing people who carefully read the sign-up and prioritizing
>> those
>> > > > who didn't. There are a lot of resources out there to help people
>> take
>> > > the
>> > > > first steps in programming. There are fewer to help with the 'what's
>> > > next',
>> > > > and I should have been more sensitive to that fact. What I should
>> have
>> > > done
>> > > > is told people who were working on novice-level skills that they
>> were
>> > > > welcome to stay and work, but that people working on the course
>> material
>> > > > would be assisted first.

Re: [Discuss] pulling along those behind

2015-10-27 Thread Noam Ross

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
> happened
> > > to
> > > > you.
> > > >
> > > > Since you're SWC, I think the first thing to do is ask the host.
> Often,
> > > the
> > > > host has some specific ideas about what they want the learners to
> come
> > > away
> > > > with, and that can help you steer the course.
> > > >
> > > > What I did, in practice, was this: I spent way too much time helping
> > > > novices. I slowed down, got through less than half of the material,
> and
> > > the
> > > > intermediates, who had actually chosen the correct class and paid a
> > > nominal
> > > > fee for it were very unsatisfied. I really think that I made the
> wrong
> > > call
> > > > by punishing people who carefully read the sign-up and prioritizing
> those
> > > > who didn't. There are a lot of resources out there to help people
> take
> > > the
> > > > first steps in programming. There are fewer to help with the 'what's
> > > next',
> > > > and I should have been more sensitive to that fact. What I should
> have
> > > done
> > > > is told people who were working on novice-level skills that they were
> > > > welcome to stay and work, but that people working on the course
> material
> > > > would be assisted first.
> > > >
> > > > On the next go around, I added a list of skills the learners needed
> to be
> > > > comfortable with to attend (previously, it had simply been a link to
> the
> > > > previous workshop) and a code snippet one of the students had
> written. I
> > > > let them know that this was the level of familiarity they needed to
> have
> > > *with
> > > > Python* to attend, and that TAs would preferentially assist those who
> > > were
> > > > mastering course skills over those who were mastering other material.
> > > >
> > > > That worked, I only had one

Re: [Discuss] pulling along those behind

2015-10-27 Thread Amanda Charbonneau

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 happened
> to
> > you.
> >
> > Since you're SWC, I think the first thing to do is ask the host. Often,
> the
> > host has some specific ideas about what they want the learners to come
> away
> > with, and that can help you steer the course.
> >
> > What I did, in practice, was this: I spent way too much time helping
> > novices. I slowed down, got through less than half of the material, and
> the
> > intermediates, who had actually chosen the correct class and paid a
> nominal
> > fee for it were very unsatisfied. I really think that I made the wrong
> call
> > by punishing people who carefully read the sign-up and prioritizing those
> > who didn't. There are a lot of resources out there to help people take
> the
> > first steps in programming. There are fewer to help with the 'what's
> next',
> > and I should have been more sensitive to that fact. What I should have
> done
> > is told people who were working on novice-level skills that they were
> > welcome to stay and work, but that people working on the course material
> > would be assisted first.
> >
> > On the next go around, I added a list of skills the learners needed to be
> > comfortable with to attend (previously, it had simply been a link to the
> > previous workshop) and a code snippet one of the students had written. I
> > let them know that this was the level of familiarity they needed to have
> *with
> > Python* to attend, and that TAs would preferentially assist those who
> were
> > mastering course skills over those who were mastering other material.
> >
> > That worked, I only had one person for whom the course was inappropriate
> > (they were too high level) show up.
> >
> > --a
> >
> > -
> > Postdoctoral Researcher
> > Iowa State University, EEOB
> > University of Kansas, EEB
> > 251 Bessey Hall
> > Ames, IA 50011
> > 512.940.5761
> > http://wrightaprilm.github.io/
> > 
> >
> >
> > On Tue, Oct 27, 2015 at 8:23 AM, Michael J Jackson <
> micha...@epcc.ed.ac.uk>
> > wrote:
> >
> >> Hi Peter,
> >>
> >> If there are more people falling behind than you have helpers to handle,
> >> then I'd just slow down. I'd (reluctantly) rather bore those who don't
> want
> >> a slower pace, than confuse those do.
> >>
> >> cheers,
> >> mike
> >>
> >>
> >> Quoting Peter Steinbach  on Tue, 27 Oct 2015
> >> 11:39:01 +0100:
> >>
> >> Hi Raniere et al,
> >>>
> >>> thanks for the pointers for recording the terminal history, I'd like to
> >>> get back to my more general question though ... how to give
> participants
> >>> that are not up to the level of the course a chance to follow? I don't
> >>> wanna drag them all through, at some point there has to be a limit for
> the
> >>> sake of the remaining crowd. But still, I'd like to hear people's
> >>> experience on this.
> >>>
> >>> Best,
> >>> Peter
> >>>
> >>> On 10/27/2015 11:23 AM, Raniere Silva wrote:
> >>>
>  Hi Peter,
> 
>  Could you share these scripts?
> >
> 
>  Please check
> 
> 
>

Re: [Discuss] pulling along those behind

2015-10-27 Thread C. Titus Brown

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 happened
> > to
> > > you.
> > >
> > > Since you're SWC, I think the first thing to do is ask the host. Often,
> > the
> > > host has some specific ideas about what they want the learners to come
> > away
> > > with, and that can help you steer the course.
> > >
> > > What I did, in practice, was this: I spent way too much time helping
> > > novices. I slowed down, got through less than half of the material, and
> > the
> > > intermediates, who had actually chosen the correct class and paid a
> > nominal
> > > fee for it were very unsatisfied. I really think that I made the wrong
> > call
> > > by punishing people who carefully read the sign-up and prioritizing those
> > > who didn't. There are a lot of resources out there to help people take
> > the
> > > first steps in programming. There are fewer to help with the 'what's
> > next',
> > > and I should have been more sensitive to that fact. What I should have
> > done
> > > is told people who were working on novice-level skills that they were
> > > welcome to stay and work, but that people working on the course material
> > > would be assisted first.
> > >
> > > On the next go around, I added a list of skills the learners needed to be
> > > comfortable with to attend (previously, it had simply been a link to the
> > > previous workshop) and a code snippet one of the students had written. I
> > > let them know that this was the level of familiarity they needed to have
> > *with
> > > Python* to attend, and that TAs would preferentially assist those who
> > were
> > > mastering course skills over those who were mastering other material.
> > >
> > > That worked, I only had one person for whom the course was inappropriate
> > > (they were too high level) show up.
> > >
> > > --a
> > >
> > > -
> > > Postdoctoral Researcher
> > > Iowa State University, EEOB
> > > University of Kansas, EEB
> > > 251 Bessey Hall
> > > Ames, IA 50011
> > > 512.940.5761
> > > http://wrightaprilm.github.io/
> > > 
> > >
> > >
> > > On Tue, Oct 27, 2015 at 8:23 AM, Michael J Jackson <
> > micha...@epcc.ed.ac.uk>
> > > wrote:
> > >
> > >> Hi Peter,
> > >>
> > >> If there are more people falling behind than you have helpers to handle,
> > >> then I'd just slow down. I'd (reluctantly) rather bore those who don't
> > want
> > >> a slower pace, than

Re: [Discuss] pulling along those behind

2015-10-27 Thread Giuseppe Profiti

Hello everybody,
since this is my first post, let me introduce myself: I'm a research fellow
at university of Bologna (Italy) and a "temporary" professor teaching
Python programming in a Bioinformatics Master's degree course. I attended
Greg's SWC "train the trainers" workshop in London 3 weeks ago.

In my opinion, everything depends on the goal. In a university course,
there is much more time to help people who fall behind. In my classes, I
try to explain a concept a second time, or even a third (quicker and
oversimplified) time if someone still says to be confused by it. Then, if
they are only 1 or 2, I move on: there is a class of 25/30 students that
need be kept interested in the subject and/or want to get the next piece of
information. Those 1 or 2 can catch up later with the help of their
colleagues or in office hours with me.
In this case, my goal is to keep students with a biological background
focused and interested in the subject, while providing useful information.
Helping few people may undermine that.
A couple of years ago I ran a post course survey, and almost everyone said
that the pace was slowed too much by helping a group of 5 students (20% of
the class). Since there is no way to know if those lagging behind are just
not interested in the course, not doing their homework or having language
issues (the course is in English), I switched to "I'll help you later"
mode. Last year worked like a charm: only 2 students had trouble passing
the exam, and they were those never asking for help (even when encouraged
to).

In a 1-day Wikimedia workshop we used a different approach. The goal in
that case was to help people feeling engaged and let them have fun with
wikipedia and other projects. Since the audience was a mixed one
(librarians, tech-savvy, people in their mid twenties and people already
retired), instead of trying to have everyone walk out with the same
competence, we scaled down the tasks for those who had more troubles. In
that way, at least they walked away without feeling incompetent and
dishearten, and maybe willing to learn more by themselves.
However, for the next workshops we planned to have a quick survey during
the registration process, then tune the level of the workshop on the skills
of the majority and turn down the application requests from those too far
from the average.

I'm new to SWC, but I think you should have faced similar problems in the
past and maybe my examples are not applicable to the current layout of the
workshops.

Best,
Giuseppe

Il giorno mar 27 ott 2015 alle ore 15:29 April Wright <
wright.apr...@utexas.edu> ha scritto:

> 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 happened to
> you.
>
> Since you're SWC, I think the first thing to do is ask the host. Often,
> the host has some specific ideas about what they want the learners to come
> away with, and that can help you steer the course.
>
> What I did, in practice, was this: I spent way too much time helping
> novices. I slowed down, got through less than half of the material, and the
> intermediates, who had actually chosen the correct class and paid a nominal
> fee for it were very unsatisfied. I really think that I made the wrong call
> by punishing people who carefully read the sign-up and prioritizing those
> who didn't. There are a lot of resources out there to help people take the
> first steps in programming. There are fewer to help with the 'what's next',
> and I should have been more sensitive to that fact. What I should have done
> is told people who were working on novice-level skills that they were
> welcome to stay and work, but that people working on the course material
> would be assisted first.
>
> On the next go around, I added a list of skills the learners needed to be
> comfortable with to attend (previously, it had simply been a link to the
> previous workshop) and a code snippet one of the students had written. I
> let them know that this was the level of familiarity they needed to have *with
> Python* to attend, and that TAs would preferentially assist those who
> were mastering course skills over those who were mastering other material.
>
> That worked, I only had one person for whom the course was inappropriate
> (they were too high level) show up.
>
> --a
>
> -
> Postdoctoral Researcher
> Iowa State University, EEOB
> University of Kansas, EEB
> 251 Bessey Hall
> Ames, IA 50011
> 512.940.5761
> http://wrightaprilm.github.io/
> 
>
>
> On Tue, Oct 27, 2015 at 8:23 AM, Michael J Jackson  > wrote:
>
>> Hi Peter,
>>
>> If there are more people falling behind than you have helpers to handle,
>> then I'd just slow down. I'd (reluctantly) rather bore those who don't want
>> a slower pace, than confuse those do.
>>
>> cheers,
>> mike
>>
>>
>> Quoting Peter Steinbach  on Tue, 27 Oct

Re: [Discuss] pulling along those behind

2015-10-27 Thread Azalee Bostroem

Hi Peter et al.

It is great to hear everyone’s thoughts. I would suggest a multi-prongged 
approach:

I always post a “Lesson plan” master notebook to the class repository. This has 
my lesson plan in it (so basically everything I plan on typing minus the 
extemporaneous stuff). I point people to this at the beginning of the lesson so 
that students who want to take a lot of notes know that the information is 
already there, students who missed something know its there, and students who 
can’t keep up with the typing can just follow along knowing that they can go 
back to it at their own pace. I also let them know that I will post my notebook 
from class to the repository as well for anything that we covered spontaneously.
I typically bring the class back from exercises when 50-65% of the class is 
finished. I let them know at the beginning of the class that I won’t wait for 
everyone, but that I will go over a solution together as a class so that if 
they didn’t finish, they can see how to finish. I do this because I realized 
that if I wait for everyone, then almost everyone has moved onto a different 
task (often not SWC related) by the time the last ones have finished. 
Explaining to the class my plan and reasoning puts the students at ease.
I like to do an informal poll at the beginning of class to get a sense of who 
may be the more advanced learners. Once they have their hands up, I explicitly 
tell the class - these are your resources, use them.
I haven’t tried this, but I think it would be useful for engagement, especially 
in a particularly split class - pair up an advanced student and a beginner 
students and have them work together. Make sure the beginner student is getting 
the opportunity to ask questions and understands what is going on (maybe 
encourage them to trade off who is typing the exercises). Explicitly assigning 
people to each other might make it easier to ask for help and to feel 
comfortable offering help.

-Azalee
---
K. Azalee Bostroem
Graduate Student
UC Davis
http://azaleebostroem.wordpress.com
---

On Oct 27, 2015, at 9:38 AM, 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.

Re: [Discuss] pulling along those behind

2015-10-27 Thread Thomas Ballinger

Hi all,

I'm not a SWC instructor but will be applying for the the group training
soon. I share this concern. Here are a few things I've found helpful that
hopefully carry over from my different teaching experience:

   1. offering exercises that can be completed at various levels ("Write a
   function that takes a function as an argument" is open ended enough that
   some students do cool creative things with it, some with prior experience
   implement map or reduce, and some type along with me on the projector as we
   write a function that calls the passed in function twice) (seconding Bill
   Mills on this)
   2. making detours for the more advanced folks instead of the beginners.
   The mental gymnastics of managing a stack of goals is distracting, so I try
   to put that burden on the experienced folks. Explicitly stating that
   something is outside the scope of the lesson and then answering an advanced
   question or sharing some trivia: in a git seminar experienced users were
   happy to go through first commit exercises if I was able to teach them a
   new flag that made committing nicer). Hopefully this keeps more advanced
   students engaged without frustrating more beginner ones, because this
   information is outside the scope of the lesson. (unfortunately it's still
   distracting)
   3. under-advertising how much material I hope to cover so people aren't
   disappointed we didn't get to something if the class moves slowly
   4. when asking students to help each other, pushing them over the edge
   by assigning pairs or calling out students that can help that can get
   students over the hump more quickly. I find students' self-reports of their
   abilities inaccurate and problematically skewed so I tend toward "everyone
   talk about this with your partner" vs "if you know this explain it to your
   neighbor."
   5. seeding the class with individuals with whom I have prior experience
   and of whom I have good mental models: since I know their prior experience,
   I can rely on them to teach background to other and use them as precise
   canaries of understanding.

Some techniques that I imagine aren't applicable in the SWC setting that I
ought to write a blog post about instead, based on working at a 3-month
programming retreat:

   1. repeatedly *invite people to leave the workshop* at specific breaks
   if they feel like they've gotten enough or aren't getting much out of the
   session. I announce that I'll run more targeted workshops in a few hours or
   the next day, run the same workshop again in a week, or work one on one
   later. It takes quite a cultural shift to make this ok.
   2. be demanding of prerequisites in the official announcement, then
   personally invite people that tend to underestimate their abilities
   3. keep class sizes small (less than 12), and if necessary to decrease
   class size require prep work (with plenty of time and office hours
   available to help people complete it). With a larger class size than this,
   I find I can't react much to people being left behind except to try to do a
   better job matching the audience and material the next time I teach the
   class.
   4. invite students to work on something else if we're at an explicit
   waiting point, "while I [and the TAs] help everyone get a text editor
   invokable from the command line, start playing with HTML as described on
   this page" and treat these as breaks
   5. provide the blog post / conference talk / video lecture version of
   the same information, and when students don't get something play the
   session off as an introduction, with more information available later for
   self-study
   6. Of the six ways to order 3 levels of workshops, I like intermediate,
   then beginner, then advanced. This way intermediates can drop down, and
   students in intermediate and beginner sessions can also attend the advanced
   workshop.
   7. have students with more questions stay after (coming early relies on
   students estimating their abilities before they've have trouble instead of
   assessing whether they actually had trouble)
   8. iterating on curriculum to make it have a bare minimum of
   dependencies - choosing specially crafted examples that focus particularly
   on a single skill without inviting too many questions about underlying
   topics to avoid rabbit hole explanations
   9. being enthusiastic and welcoming about questions which reveal a
   student's lack of background or misunderstanding and being concise and
   informative enough in answering them that advanced students learn something
   (it's an aspirational goal)

Thomas Ballinger

On Tue, Oct 27, 2015 at 1:19 PM, Azalee Bostroem 
wrote:

> Hi Peter et al.
>
> It is great to hear everyone’s thoughts. I would suggest a multi-prongged
> approach:
>
>
>1. I always post a “Lesson plan” master notebook to the class
>repository. This has my lesson plan in it (so basically everything I plan
>on

Re: [Discuss] pulling along those behind

2015-10-27 Thread Jan Kim

On Tue, Oct 27, 2015 at 04:33:37PM +, 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.

Another pattern that in my experience is somewhat typical is that
students try to catch up by any means, which frequently include
stages of typing lines of code with increasingly little time / chance
to reflect on their meaning, asking instructors / helpers / neighbours
what to type, and cutting / pasting material. (For this reason, some
instructors are reluctant about pointing students to notes ahead of lessons.)

I generally try to summarise concepts covered frequently, so that
those who have struggled to keep up (in terms of typing or figuring
out what it means) still get a chance to understand the key concepts
and to re-join on that basis. In terms of SWC materials, the learning
objectives itemised at the start of each lesson are a very good source
of concepts to summarise.

Best regards, Jan


> 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
> > happened
> > > > to
> > > > > you.
> > > > >
> > > > > Since you're SWC, I think the first thing to do is ask the host.
> > Often,
> > > > the
> > > > > host has some specific ideas about what they want the learners to
> > come
> > > > away
> > > > > with, and that can help you steer the course.
> > > > >
> > > > > What I did, in practice, was this: I spent way too much time helping
> > > > > novices. I slowed down, got through less than half of the material,
> > and
> > > > the
> > > > > intermediates, who had actually chosen the correct class and paid a
> > > > nominal
> > > > > fee for it were very unsatisfied. I really think that I made the
> > wrong
> > > > call
> > > > > by punishing people who carefully read the sign-up

Re: [Discuss] pulling along those behind

2015-10-27 Thread Greg Wilson

If anyone would like to summarize the discussion in a blog post (which 
we could then include in instructor training), I'd be very grateful, and 
so would future generations of instructors.

Cheers,
Greg

___
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

2015-10-27 Thread David Dotson

When teaching Python, I have a keyboard shortcut set up to push my live-coding 
notebook to a repository on github. At the beginning of the lesson I post the 
link to the etherpad and let learners know that this is a good tab to keep open 
for when they want to see cells I've long since scrolled past, or if they want 
to copy-paste blocks of code they perhaps didn't manage to finish that are 
useful for later. Getting the latest version of what I've done is just an  
away. Since github now renders notebooks, this works quite well.

Next time I might make this an every-minute cron job so that I don't have to 
remember to hit the shortcut every so often.

I don't have a good solution for things run from the terminal, except perhaps 
setting the history file to go to Dropbox, which I've seen done before.

David

___
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

2015-10-27 Thread Christina Koch

Great discussion all!  I second Greg's motion - would be great to have this
summarized and archived as a resource for future use.

Christina

On Tue, Oct 27, 2015 at 4:38 PM, David Dotson  wrote:

> When teaching Python, I have a keyboard shortcut set up to push my
> live-coding notebook to a repository on github. At the beginning of the
> lesson I post the link to the etherpad and let learners know that this is a
> good tab to keep open for when they want to see cells I've long since
> scrolled past, or if they want to copy-paste blocks of code they perhaps
> didn't manage to finish that are useful for later. Getting the latest
> version of what I've done is just an  away. Since github now renders
> notebooks, this works quite well.
>
> Next time I might make this an every-minute cron job so that I don't have
> to remember to hit the shortcut every so often.
>
> I don't have a good solution for things run from the terminal, except
> perhaps setting the history file to go to Dropbox, which I've seen done
> before.
>
> David
>
> ___
> Discuss mailing list
> Discuss@lists.software-carpentry.org
>
> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
>



-- 
Christina Koch - Research Computing Facilitator,
University of Wisconsin - Madison, Center for High Throughput Computing
Advanced Computing Initiative; Wisconsin Institute for Discovery; ACI-REF
___
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

2015-10-27 Thread Anelda van der Walt

We're running a SWC workshop next week and it will certainly benefit me to
read thoroughly through the posts.  I am happy to start summarising as I
read and share with others to add what I've missed

Anelda

-Original Message-
From: Discuss [mailto:discuss-boun...@lists.software-carpentry.org] On
Behalf Of Greg Wilson
Sent: 27 October 2015 11:08 PM
To: discuss@lists.software-carpentry.org
Subject: Re: [Discuss] pulling along those behind

If anyone would like to summarize the discussion in a blog post (which we
could then include in instructor training), I'd be very grateful, and so
would future generations of instructors.
Cheers,
Greg

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


___
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

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

[Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

Re: [Discuss] pulling along those behind

30 matches

Site Navigation

Mail list logo

Footer information