Re: [Discuss] conda and Git BASH

[Giuseppe Profiti]

I opened a similar discussion about one month ago, you can find it in the
repository
https://github.com/swcarpentry/python-novice-inflammation/issues/485

Best,
Giuseppe


2018-03-19 12:53 GMT+01:00 Will Trimble :

> Instructors who don't have Windows can rent the use of a windows
> environment by the hour from Amazon:
>
> https://software-carpentry.org/blog/2014/06/fixing-14-repositories.html
>
> It is very enlightening to play with an unfamiliar operating system the
> night before a workshop, where cut-and-paste has an unfamiliar key binding
> and all the functionality is in the wrong place.
>
> w
>
>
> On Sun, Mar 18, 2018 at 7:21 PM, Damien Irving 
> wrote:
>
>> Hi all,
>>
>> I'm developing a new set of Data Carpentry lessons for atmosphere and
>> ocean scientists. Upon teaching the lessons for the first time, I had some
>> issues using conda and Git BASH (on windows machines). In particular, after
>> installing Anaconda and Git BASH the "conda" command wasn't available from
>> the Git BASH command prompt, nor was "source activate" for activating conda
>> environments. I've spelled out all the details at the following GitHub
>> issue:
>> https://github.com/data-lessons/python-aos-lesson/issues/3
>>
>> I don't have a windows machine to play around on (nor do I have much
>> experience in configuring Git BASH), so I was wondering if anyone has some
>> knowledge/experience with this kind of thing?
>>
>>
>> Regards,
>> Damien
>>
>> ___
>> Discuss mailing list
>> Discuss@lists.software-carpentry.org
>> http://lists.software-carpentry.org/listinfo/discuss
>>
>
>
> ___
> Discuss mailing list
> Discuss@lists.software-carpentry.org
> http://lists.software-carpentry.org/listinfo/discuss
>
___
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/listinfo/discuss

Re: [Discuss] resources on how to manage a virtual team

[Giuseppe Profiti]

2018-02-26 19:21 GMT+01:00 Karin Lagesen :

> I find myself in the position of being a work package leader for a EU
> project. I don't know any of the ones that will work with me in this work
> package, and they all work at different institutions all over Europe. To
> boot, I have never managed a EU work package before.
>
> Thus, I am looking for tips, links, books, whatever you might know of that
> might help me forge these people into an actual team that gets stuff done.
> I know there are a lot of researchers and others on this list that might
> have been in the same situation as me, which is why I thought asking via
> this list might garner some good results.
>
> Thanks in advance,
>
> Karin
>

Hello Karin,
I would suggest to look into ELIXIR materials to see if there is any "best
practices" about managing teams, given that most of the work is done across
all Europe. On the ELIXIR F1000 channel
https://f1000research.com/gateways/elixir I see nothing that applies,
however.
By experience, most of the work in ELIXIR is done via shared documents
(e.g. google docs), open repositories (github), monthly calls open to all
participants. I expect that WP leaders will be in closer communication.
Some text and few links about the subject can be found in wikibooks
https://en.wikibooks.org/wiki/Managing_Groups_and_Teams/How_Do_You_Manage_Global_Virtual_Teams%3F
but I can't vet on its quality.

Best,
Giuseppe
___
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/listinfo/discuss

Re: [Discuss] Familiar Contexts and the Difficulty of Programming Problems

[Giuseppe Profiti]

2017-12-05 18:19 GMT+01:00 Greg Wilson :

> A result that may be of use in designing Carpentry lessons (from
> https://doi.org/10.1145/3141880.3141898):
>
> Intuition suggests that problems from a familiar context should be easier
>> to solve than the same problems described using an unfamiliar domain.
>> However, prior work on contextualized programming problems has found little
>> evidence to support this hypothesis. In this paper, we extend this work by
>> exploring the use of a particular familiar context: problem domains used
>> earlier in an introductory programming course. We conduct a crossover
>> design study in a large introductory programming course to compare problems
>> with and without context related to previous coursework. Our results
>> suggest that any advantage conveyed by a familiar context is dominated by
>> other factors, such as the complexity of terminology used in the
>> description, the length of the problem description, and the availability of
>> examples. This suggests that educators should focus on simplicity of
>> language and the development of examples, rather than seeking contexts that
>> may aid in understanding problems.
>>
>

Thanks Greg,
This is a confirmation of something we are experiencing in classroom.
However, I found the familiar domain useful not for the specific
programming problem, but rather for showing how programming is not
something different from other "common" activities (e.g. I usually start
with a "let's plan a vacation" example to show how a problem can be split
in subproblems and the different solutions for the same subproblem). That
sometimes helps in overcoming some skepticism. However, this is only
anecdotal evidence and not a proper scientific analysis.

Giuseppe
___
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/listinfo/discuss

Re: [Discuss] what mistakes would you like to see me make in a teaching video?

[Giuseppe Profiti]

- +1 on ideas out of order, like postponing the explanation of
something you are using ("It's magic!")
- assuming previous knowledge about something ("As you all know..")
- never looking at the audience for a while ("it's talking to himself")

Best,
Giuseppe

2016-04-20 17:14 GMT+02:00 Mike Smorul :
> - Related to #3 is also diverging from the students environment. Your
> IDE/terminal looks visually different from theirs (colors, menu/window pane
> placement, etc)
>
> - Forgetting to checkpoint w/ the class and make sure they’re still
> following along.
>
>
>
>
>
> From: Discuss [mailto:discuss-boun...@lists.software-carpentry.org] On
> Behalf Of Ashwin Trikuta Srinath
> Sent: Wednesday, April 20, 2016 11:00 AM
> Cc: Software Carpentry Discussion 
> Subject: Re: [Discuss] what mistakes would you like to see me make in a
> teaching video?
>
>
>
> Live coding mistakes like:
>
>
>
> 1. alt-tabbing too much
>
> 2. Typing too fast
>
> 3. "I'm going to cheat a little here and [uses vim in visual block mode]",
> but you can just use nano to do the same
>
>
>
> :-)
>
>
>
> On Wed, Apr 20, 2016 at 10:52 AM, Greg Wilson
>  wrote:
>
> Hi,
>
> We ask instructor trainees to create and critique short videos of themselves
> teaching (both stand-up and live coding). To prepare them for this, I would
> like to record a 90-second video of myself teaching; to ensure it's useful,
> I'd like to give viewers stuff to critique. So: what mistakes would you like
> the video to include in both content and presentation? Things I've already
> thought of are:
>
> * too much jargon
>
> * ideas presented out of order
>
> * lots of 'um' and 'er' (or using the word 'like' in every third breath,
> which is almost as bad as someone cracking their knuckles behind you during
> a thermodynamics exam when you're stuck on question 3, which has nothing at
> all to do with the course material)
>
> Please let me know what else you'd like to see by adding comments to
> https://github.com/swcarpentry/website/issues/343 (rather than replying
> directly to this list).  I can't possibly live up to
> https://www.youtube.com/watch?v=FQjgsQ5G8ug=youtu.be=35, but I'll
> give it my best shot...
>
> Thanks,
> Greg
>
> --
>
> Dr Greg Wilson
>
> Director of Instructor Training
>
> Software Carpentry Foundation
>
>
> ___
> 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

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

Re: [Discuss] Any tips for learning R and Python?

[Giuseppe Profiti]

Hi Jason,
I'm going to answer to just one of your points.

2016-03-30 8:09 GMT+02:00 Jason Bell :

>
> · Do you think “instructors” should know more than just the
> teaching material for the “subjects” they plan on teaching.  For example, I
> recently ran a local “UNIX Shell” locally and given I have been using bash
> for over 15 years, I was extremely comfortable with the teaching material
> (even though I did pick up a few tips and tricks), there were no unexpected
> questions that I could not answer.  I doubt this would be the case with R
> or python, as I don’t use it regularly enough to feel competent to answer
> left field questions.  Now, I appreciate that you cannot know everything,
> but having a greater knowledge than just the 3-4 hour lesson material would
> like highly desirable – thus would welcome any suggestions in resources,
> training material that could help me to get up to speed ASAP.
>
IMHO, it depends on your audience. Audience questions may vary from no
questions, to "can I do that with Python?", up to "I would like to use
multiple threads while connecting to a remote server using a VPN".
In the first case, i.e. learners without any knowledge, it is more
important to convey the basic idea and to empower them, that to know a lot
of things.
In the second case, you should know the existence of a specific library,
even if you never used it. "There is sklearn for that" is a correct answer,
even more when there is only one person asking for that and then going into
details may confuse the others.
The last case, the one with power users, requires a lot more.

Best,
Giuseppe
--
University of Bologna, italy
___
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org

Re: [Discuss] Phrases to avoid when teaching

[Giuseppe Profiti]

Hi Titus,
I have a couple of questions about your mail.

2016-03-25 14:52 GMT+01:00 C. Titus Brown :
> My usual response to the question of "what programming language should I
> learn?" is:
>
> * Python or R, because those are the two languages being used by many
>   computational scientists, being actively developed, and with rich
>   existing ecosystems of libraries and tutorials;
>

Don't you think that specifying something may lead the trainee to
think "I should know that" or "Those are the only ones worth
considering"?
In a way, this may be equivalent to "To solve every problem, you
*just* use language X".

> * choose between them based on your local friendly help - if you have
>   a lot of R folk down the hall, learn R, and vice versa;

This is true, but how often someone does not ask because "I'm the only
one not knowing that. Everyone else knows then I should know too"?
How often a community moves from helpful to menacing?

>
> * once you know one, you can pick up another language much more easily than
>   you might believe;

Agree.

Best,
Giuseppe

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

Re: [Discuss] Phrases to avoid when teaching

[Giuseppe Profiti]

Related, even if not properly in topic.
While attending the SWC train the trainers course in September, I took
a note about the "just" and how to keep an I-can-do-it attitude in the
learners.
Then, in January, I had the chance to try to be more aware of that
while teaching Python in a Master's degree course (70-80% of students
.usually have a background in biology or biotech).

Of course that was a different setting: students believe having more
time to grasp the material with respect to a short workshop, they may
be less prone to give up during class, but they could do it anyways or
maybe give up later when you are not there to answer questions.

Anyways, "what is the best programming language?" is something that
they asked. I have my programming language of choice, but the
demotivation section in SWC guidelines helped in devising a better
answer than "I like that, but you choose whatever you want".
Instead, I told them that the best programming language is the one
they feel more comfortable with. That "if", "for" and functions are in
almost every programming language and that after getting it in python
they could move to something else. And that if someone in their future
place of work would tell them "You should use X because is better!",
they may give it a try, see if they like it and maybe toss it in the
trash bin if not.

Maybe I was wrong or there may be a better phrased answer. In that
case, a feedback from you would be more than welcome.

To be in topic: instead of thinking about it as "I must not do that",
those guidelines could also be used as "how can I convey that
information in a better and less threatening way?".

Best,
Giuseppe



2016-03-24 22:44 GMT+01:00 Greg Wilson :
> One approach is to pre-empt it - I make a point of saying in my intro that
> this stuff is genuinely hard, that I shouldn't imply otherwise by saying
> "just" (or equivalent), and inviting people to keep score.  We can then
> compare everyone's scores at the first coffee break, and since they're never
> the same, we can then have an interesting discussion about real-world data
> :-)
> Cheers,
> Greg
>
>
> On 2016-03-24 5:41 PM, Adam Obeng wrote:
>>
>> Does any one have a tip for how to recover from accidentally doing these
>> things? I've tried to explain why I'm apologising for saying "just", but
>> that *just* seems to make it worse.
>>
>> Cheers,
>>
>> Adam
>>
>> On Thu, Mar 24, 2016, at 05:30 PM, Steven Haddock wrote:
>>>
>>> Yes, I think that is the one. The J-word!!
>>> Thanks Lex.
>>>
>>>
>>>
 On Mar 24, 2016, at 14:22 , Lex Nederbragt 
 wrote:

 Perhaps this helps? Look for "Things You Shouldn't Do in a Workshop" on
 http://swcarpentry.github.io/instructor-training/09-motivation.html

Lex

> On 24 Mar 2016, at 22:02, Steven Haddock  wrote:
>
> TL;dr Can someone point me to the post about teaching guidelines?
>
> A little while ago Greg or somebody posted a set of examples of things
> to avoid saying (“You can simply…”, etc).
>
> A friend of mine (really!) is teaching a class and she realized she
> should avoid saying “You have probably all done X”… so I was going to send
> her that post, but I can’t find it.
>
> Thanks,
> Steve
>
>
> ___
> 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
>>
>> ___
>> Discuss mailing list
>> Discuss@lists.software-carpentry.org
>>
>> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
>
>
> --
> Dr Greg Wilson
> Director of Instructor Training
> Software Carpentry Foundation
>
>
>
> ___
> 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] Leave students by themselves during hands-on

[Giuseppe Profiti]

Thanks everybody, this discussion is highlighting a lot of interesting
points and materials.
Just one remark: the course that inspired my question was not a SWC
one, it was a training on analysis softwares (i.e. cytoscape and
others) for biologists.
But since education methods are common to SWC, training like that one
and the more formal university-level courses, I was interested in what
kind of practice/hands-on could be more effective for the two main
purposes
- avoid scaring the students and, possibly, encourage them into be
positive while approaching the topic
- maximize the amount of knowledge and skills gained in the course

Thanks again!

Best,
Giuseppe

2016-03-10 7:40 GMT+01:00 W. Trevor King :
> On Sun, Mar 06, 2016 at 05:41:12PM +, Code, Warren wrote:
>> … the Kirschner, Sweller, and Clark article [3 in Trevor's comment]
>> can be a bit of a tricky entry point into the literature…
>
> Better (ideally open) entry points are welcome ;).  It looks like
> there is more good stuff and a number of references in [1], although
> that lacks a DOI, clear author information, and possibly peer review.
>
>> For the SWC lesson provided as an example here, there was certainly
>> substantial guidance [snip scaffolding] they were asked to practice
>> the kinds of things that people encounter in scientific computing
>> (dealing with unknown data files, grappling with unexpected bugs,
>> etc.) and had relatively on-demand support from the helpers and
>> other participants.
>
> I agree on the potential for good scaffolding, although it's easy for
> an hour of student-lead exercises to end up being “throw them into the
> deep end” instead of “the shallow end of the pool is over there,
> instructors will be circulating, and lifeguards are standing by for
> anyone that calls out or looks distressed”.  I think Giuseppe's:
>
> * “by themselves” in the subject,
> * “some were stuck at the first [problem]” and “forced to think about
>   the problems they were facing and to ask for help” in the body.
>
> gave me the impression that this workshops dispensed with the
> circulating instructors and just kept the lifeguards.  For some people
> that will be fine.  But folks are probably in a face-to-face SWC
> workshop because they're not comfortable working through the SWC
> lessons (or other online tutorials) on their own, so I think it's
> useful to have more instructor/helper-initiated interaction.
>
>> [snip reasonable thoughts about scaling practice periods with
>> exercise complexity].  If there is a widespread difficulty that
>> isn't terribly interesting to the main ideas, like the GUI bugs,
>> maybe having a shorter cycle of "try this - did everyone get this
>> error - this is why, there's this bug" would be warranted before the
>> longer period working alone.  In my experience, the only practical
>> way to discover these sort of difficulties is to run the lesson,
>> collect that sort of information, and do it differently the next
>> time. :)
>
> I'd certainly recommend avoiding known library/tooling bugs in the
> first two days that folks are coding.  The existing SWC lessons are
> fairly narrowly scoped (e.g. see the “other 90%” phrasing [2]), and a
> tool with novice-noticeable bugs in the most fundamental 10% is
> probably not a good tool to introduce to novice programmers ;).  But
> yeah, sometimes it's not clear that a particular exercise will be
> confusing until you put it in front of people, so +1 on emphasizing
> evolutionary lesson polishing.
>
> Cheers,
> Trevor
>
> [1]: http://www.deansforimpact.org/the_science_of_learning.html
>  
> https://github.com/swcarpentry/instructor-training/blob/58c6942bc6d910d7f886098c231b4d107c9ff0c3/papers/science-of-learning-2015.pdf
>  Deans for Impact (2015).  The Science of Learning.  Austin, TX: Deans 
> for Impact.
> [2]: 
> https://github.com/swcarpentry/python-novice-inflammation/blob/v5.3/instructors.md#overall
>
> --
> This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

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

[Discuss] Leave students by themselves during hands-on

[Giuseppe Profiti]

Dear all,
during a recent training course (not a SWC, but we used many of its
techniques while showing how to use few software for analysis), we had many
trainers and some of them had an approach to exercises that I found
strange. After the course we discussed that, since I was interested in
their point of view.

The lesson was something like that: less than 1 hour of explanation, then
exercises were presented and the students had 1 hour or a bit more to
complete them. Using colored stickers, students could attract our attention
when they needed help.

I was a bit skeptic about this approach: the students had no clue about the
content and the format of the input file provided, some of the steps
required knowledge about a couple of bugs in the software UI, and there was
no explanation on the expected output (or on the meaning of the output,
when there was more than one result). Also, given the length of the session
there was no way to adjust their pace: few finished almost all the
exercises, some were stuck at the first one and so on.

However, another trainer pointed out that in this way the students were
forced to think about the problems they were facing and to ask for help.

In my opinion, while error messages or wrong results are good for learning
(i.e. by showing an error message it is possible to explain the importance
of reading them to understand the problem, while running a software with
wrong settings is useful to introduce new parameters and options), I found
that frustration may be the most probable outcome.
Also, explaining the correct usage of a (bugged) software to each single
person that asks for help may be a waste of time.

Since the strategy of splitting the presentation in short chunks, exercise
often nad build from previous results is something I fell more familiar, I
would like to know your opinions about that.

Thanks in advance for your help.

Best,
Giuseppe
--
Adjunct professor - International Master's degree in Bioinformatics
Post-doctoral Research Fellow - Biocomputing Group
University of Bologna, Italy
___
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org

Re: [Discuss] for loop metaphor

[Giuseppe Profiti]

Hello,
just to add a couple of metaphors I already used in a programming course
(not in SWC, but in a Master's degree in bioinformatics).
The first one is "Your boss asks for 20 flasks of a solution. You get the
first flask, add water, add the solute, put the flask away from the empty
ones, repeat the same procedure for every flask. Do you have to change
something if the flasks are 30? 100? If you use a different solute, do you
have to change a lot in this procedure?"
The second one aims to introduce the concept of many operations on each
item, by trying to move away from the single activity per item. "We want to
compute the average height and the distribution of hair colors of the
people in the room. I could call you one by one, ask for the height,
perform the summation and, after everyone showed up, divide the value by
your number. Then I call you again, one by one, and ask for hair color. In
this way, you have to stand up twice, wasting a lot of time, while I could
instead ask for height AND hair color while it is your turn in the queue".
After that, I usually re-use the queue metaphor to introduce nested loops,
i.e. for each person in the queue a clerk asks for each item in a checklist
list.

Best,
Giuseppe


Il giorno gio 3 dic 2015 alle ore 11:43 Greg Wilson <
gvwil...@software-carpentry.org> ha scritto:

> Matt Davis built a very cool module for the Jupyter notebook called
> ipythonblocks that rendered small images using HTML and CSS -
> http://ipythonblocks.org/ seems to be down right now, but you can grab
> the plugin at https://github.com/jiffyclub/ipythonblocks.  As Guzdial &
> Ericson showed, it's a great way to teach loops and conditionals, array
> indexing, and a bunch of other things.  Mike Hansen built the
> "skimage.novice" module to provide similar functionality on top of SciPy's
> image manipulation as a bridge between the simple-but-slow and the
> real-but-harder-to-understand (
> http://scikit-image.org/docs/stable/api/skimage.novice.html).
>
>
> G
>
>
> On 2015-12-03 10:32 AM, Lukas Weber wrote:
>
> Hi Karin,
>
> I like the example about pixels in an image. For each pixel in an image
> (row by row), do something, for example convert color to grayscale. Most
> students have a good intuition about images, pixels, and other media
> examples.
>
> I think this was from the "media computation" examples in Mark Guzdial's
> "Why Is It So Hard To Learn To Program" paper:
> http://files.software-carpentry.org/training-course/2012/08/guzdial.pdf
>
> Lukas
>
>
> On Thu, Dec 3, 2015 at 11:19 AM, Juan Nunez-Iglesias 
> wrote:
>
>> Ha! I like the egg metaphor + demo. One thing I would suggest is to
>> change the variable from "egg" to "egg_in_hand". People in my workshop
>> seemed to have the most trouble with the idea that each element was being
>> assigned to the variable name in the for loop. With "egg_in_hand", you can
>> demonstrate the assignment that's happening.
>>
>> Either way, I like all the different applications of your metaphor. You
>> can teach programming *and* make a cake, all in one session!
>>
>> Juan.
>>
>> On Thu, Dec 3, 2015 at 9:01 PM, Ian Hawke  wrote:
>>
>>> One example that I've used in words, and want to try in reality:
>>>
>>> Take an eggbox with one row of eggs.
>>>
>>> for egg in eggbox:
>>> crack(egg)
>>>
>>> and then take them out one at a time and crack them (into a jug, I
>>> guess).
>>>
>>> Alternatively, number the eggs with a permanent marker from 0, and use
>>> this to display list access.
>>>
>>> Main reason for doing this with an eggbox is that it extends to two
>>> dimensions, so the metaphor can extends to numpy array examples with two
>>> indices, which always seems to cause more issues.
>>>
>>> Ian
>>>
>>>
>>> On 03/12/2015 09:24, Karin Lagesen wrote:
>>>
 The more I teach, the more I realize that I am not really able to
 convey what a for loop does to everybody. Do any of you have a metaphor or
 something that you use for teaching it? I explain about variables and
 collections, and the body of the loop, and I show examples, but I am still
 not able to get through all the time.

 Karin

 ___
 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
>>>
>>
>>
>> ___
>> Discuss mailing list
>> Discuss@lists.software-carpentry.org
>>
>> http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org
>>
>
>
>
> ___
> Discuss mailing 
> 

Re: [Discuss] pulling along those behind

[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