Novices only tracks? Or No R experience workshop pace? Or a Theoretical introduction to coding for non-coders

[jas58]

Hi Team, I wondered after hearing from a colleague who attended a Carpentry workshop (with Visualizations in R): Given that there are always learners who know some R or coding and want to rush to see the visualizations Given there are novices who only sign up for Carpentry workshops because the advanced buzz words appear in the description or title Given the andragogy of live coding at tempo-de-learner I propose two (or more) flavors of workshops. The first flavor is expressly for novices (to explain to slightly experienced users that this workshop will be frustratingly slow). The second flavor is variable, based on previous experience or the pre-assessment, to allow some bored instructors to rush past the necessary pre-requisites, and get to the hard stuff.

I think my original words were:

Can there be a novices only option? Or "already done R (no beginners)" options for workshops? The race to keep the advanced users interested is not reflecting well on the pedagogy.

And would I write up a suggestion or an email for curriculum committee about a theoretical introduction for coding for non-coders?

---

[acrall]

Tagging @ErinBecker as the Curriculum Team lead

[tobyhodges]

Thanks for raising this @jas58. It chimes with my personal experience of teaching workshops, and also reflects the observation that variations around the question "How should I manage a wide range of prior experience in a group of learners?" is one of the two most commonly-asked questions whenever I host Community Discussion calls with Instructors*.

Given that there are always learners who know some R or coding and want to rush to see the visualizations Given there are novices who only sign up for Carpentry workshops because the advanced buzz words appear in the description or title Given the andragogy of live coding at tempo-de-learner I propose two (or more) flavors of workshops. The first flavor is expressly for novices (to explain to slightly experienced users that this workshop will be frustratingly slow). The second flavor is variable, based on previous experience or the pre-assessment, to allow some bored instructors to rush past the necessary pre-requisites, and get to the hard stuff.

A common theme in the advice I have heard from Instructors is that this problem is best avoided with clear statements of the target audience in advance of the workshop, so I think you are on the right track in proposing multiple "flavours" of workshop that are explicitly intended to cater to different audiences.

The Software Carpentry Curriculum Advisory Committee (CAC) was asked in the past to define pathways through lessons e.g. the "bare minimum" that Instructors should try to cover in a workshop, given that, for Software Carpentry as with most of The Carpentries curricula, it is... challenging to teach the entirety of all the lessons in the standard two-day span. This discussion has faced stiff competition for the CAC's attention from other important matters, and no conclusion has been reached yet.

If you would like to propose this to any of the other CACs to discuss, I recommend that you do so by sending a message to their respective mailing lists: you can find the addresses for those on the Curriculum Advisors page of The Carpentries website. This is the path towards "official" recommendations of curriculum content for different flavours of workshop.

Less officially, I think it could also be very helpful to reflect Instructors' experience with adapting the lessons to audiences with different levels of expertise in the Instructor Notes of the lessons. Pull requests to add this kind of information to those pages ought to be well received.

And would I write up a suggestion or an email for curriculum committee about a theoretical introduction for coding for non-coders?

I think this would be an extremely helpful lesson for the community. It reminds me of a couple of things:

1. The proposed lesson on Foundational Computing Skills, which started out as a proposal to The Carpentries Incubator, which became this (dormant) lesson repository, and prompted this long thread on the discuss mailing list. While not an introduction to coding, it was intended to provide novice learners with some of the skills and conceptual understanding that our lessons assume e.g. unzipping archived files, knowing how to locate particular files/folders within the filesystem.
2. Belinda Weaver's workshop on Introducing Computational Thinking, which "is for researchers at all career stages who want to understand the uses and the building blocks of computational thinking. This skill is useful for all kinds of problem solving, whether in real life or in computing." I believe this may be considered soon by the LC-CAC for adoption into Library Carpentry.

* The other being variations around "How can I avoid losing at least half an hour to installation troubleshooting at the beginning of a workshop?"

[tobyhodges]

I want to follow-up with some points that reflect (only) my opinion as an Instructor on balancing the pace for learners with different prior experience/knowledge.

[personal experience/opinion] As an Instructor, it is really difficult to teach a workshop knowing that some sections of the audience are inevitably getting frustrated by the pace, and especially so when that frustration or boredom manifests in disruptive behaviour. So it is understandable to want to find a way to keep everyone happy. I am aware of Instructors having adapted their workshop content to an audience, e.g. based on responses to the pre-workshop survey indicating that they can expect a certain level of familiarity among the learners with the tools/concepts being taught. However, I think we need to be really careful about doing this because of the damage we can do to the confidence/motivation of the one or two complete novices that may be present among all those other learners who have previous experience of the shell/another programming language, etc.

One of the major strengths of The Carpentries, which is fairly unique among the approaches to training I have experienced, is the emphasis placed on not leaving anyone behind. By prioritising learners without background/prior knowledge in the skills we teach, we make workshops more inclusive and hopefully build diversity in the community.

You were proposing advertising workshops for particular audiences, which I think is a really good way to go. But unless the workshop was specifically advertised as being unsuitable for novices, I do not believe that Instructors should be engaging in a race to keep the advanced users interested.

[/end personal experience and opinion]

[ErinBecker]

Thanks so much for this question and suggestions @jas58 and to @tobyhodges for sharing thoughts and potential paths forward!

[jas58]

Thank you, @tobyhodges and @ErinBecker It really helps me to hear this reinforcement from you, with the historical context and current developments. I'm interested to support this volunteer organization, especially the new(ish) instructors and maintainers navigating where and how to catch up on "what to keep."

Now to explore how to share these. On Slack maybe?

Adding highlights from links above: CAC: Episodes 1-5 might be "core" while episodes 6-14 are more optional/stretch to customize with local audience needs, but hard to identify without discussion in Instructor Notes?

Planets story replacement: excellent outline of community steps to crowd source ideas, work, and timeline for these types of changes.

Incubator Foundational CS: I've linked the Issues list as it might be clearer than the full repo. I may add an issue about theoretical concepts of coding there, though wonder how it fits with the other suggested episodes.