Pulling In Those Left Behind

This post originally appeared on the Software Carpentry website.

A common challenge that arises before or during a workshop is that participants' prior expertise in programming or broadly speaking their abilities of using computers for science is distributed randomly. At best, this distribution peaks at the expectations of the instructor. Usually, this distribution is quite wide and thus a considerable portion of the participants do lack the necessary predispositions for the workshop level, or have a slower learning rate or simply are too shy to ask questions. I recently taught a follow-up workshop to the Software Carpentry (SWC) Novice material and struggled to keep the pace of teaching at a level so all learners would come along. Given the feedback on the SWC mailing list (see the original post), this problem occurs quite often. Thus, this blog post is a summary of the discussion initiated among fellow SWC instructors on how to pull in those learners again that fall behind or how to pace/design a course so that a minimal portion of learners fall behind.

Before running a course, it is very important to communicate the level of the course as precisely as possible to all those interested. This entails a list of topics to be covered (potentially even a under-advertised one so nobody is dissappointed), a pre-assessment form (along the lines of SWC pre-assessment), and potentially a piece of source code that illustrates the expected proficiency (April Wright). The latter being more important for intermediate learners. All of this should happen in close cooperation with the organizing host. Still, we have to expect a portion of the participants to be in a somewhat too-demanding course for their expertise (Greg Wilson) or who take "no prior computing skills" too literally (Amanda Charbonneau) and can barely type.

Another approach (Bill Mills, Thomas Ballinger) is to portion the material in slots of 30 minutes and have reassurance questions (multiple choice with partner discussion afterwards) as well as some exercises. The exercises should have one "baseline" problem dedicated to the expected level after the session, so that every learner is aware that he should tend to this first. There could/should also be at least one more problem for more advanced students as well.

Often, participants are left behind as they become out-of-sync with the live coding on the projector. Mike Jackson (SSI, UK) has come up with a simple tool to "stream" the terminal history to an online resource, so that participants can go back at their liking. The details are covered in an earlier SWC discusson (July 2014) or in the 19th workshop debriefing session. Other than that, there are terminal screen recorders available that might do the job as well: showterm.io, asciinema.org, ... If possible, the terminal cast or history should be included in the workshops webpage. David Dotson notes that he commits his jupyter notebook by pressing a custom keyboard shortcut which then triggers an automated push to github. As github renders jupyter notebooks, this has proven very worthwhile. David also notes that this could be done by cron-job launching every minute.

One common suggestion is to invite more advanced learners to step up if TAs are not available and help other participants that tend to fall behind easily (Titus Brown, Greg Wilson). In practise, this approach is often hard to implement by means of broadly asking the participants to step up (Peter Steinbach). Azalee Bostroem suggested that she plans to do an informal proficiency poll at the beginning of a course. Once more advanced learners have their hands up, she would emphasize to the not-so-advanced students that these people should be their resources in the forth-coming workshop and motivate novices to use them. Azalee and Thomas Ballinger also suggest explicit pair programming of advanced and novice learners after pairs have been assigned based on the abovementioned upfront poll. The novices might have more resources then to follow and ask questions rather than struggle with typing and coming along.

Further, some instructors suggested to hand out the materials up front so that learners can turn to that at any time. I personally switch online from the prepared materials to live-coding: the materials also contain the learning objectives which serve me as a guiding lighthouse during the process help guide my teaching and help learners understand where we are goingof course this way students were already in touch with them. Also, many instructors underlined the importance of reiteration, to rephrase taught concepts for those that didn't digest them the first time.  Certainly though this is a two-side sword, Thomas Ballinger suggests an alternative mental approach on this: reiterating concepts in other words be done with the advanced in mind so they can fortify their knowledge from a different novices, while the novices get a chance to try again on the very same concept (I find this sentence confusing, isn't re-iteration intended to help the novices rather than expert learners?).

A lot of fellow instructors emphasized that a central danger is that learners falling behind have a tendency to become frustrated and eventually give up. It was pointed out by Karin Lagesan that being lost with the little things is to be accepted as long as learners keep track of the general concepts of SWC materials. After all, instructors cannot expect a scientist to turn a programmer during a course. Instead an atmosphere of frustration tolerance should be created (Karin Lagesan, Sam Penrose, David Martin), where learnes accept the fact that they'll often run into errors and build up a frustration resilient mindset.

To sum up, it is a given that learners will come to workshops with a variety of programming/computing experiencehave different preconditions when entering SWC (or any other) courses. We as instructors need to make sure that the pace of teaching suits the majority as the slower learning of a minority could and should never impact the learning success of the majority. However, clear communication upfront, constant feedback during the workshop, pair programming and well suited problems that are tailored to those present can help equalize the differences.  Keeping the above suggestions in mind can ensure all learners get the most out of the workshop, which is the goal of Software Carpentry.