Pre-requisites for instructor training

[gvwilson]

What should people be required to know before starting instructor training? How will we ensure that they know it? How will we avoid discouraging people from taking part by putting a prerequisite list in place?

[SaraVarela]

Hi,

I do not think people will be "afraid" if you set some prerequisites for this course. I think it is realistic. You can split the courses in several levels if needed.

If you do not set any prerequisite you will end up with an heterogeneous group of people, which means that some people are going to be master programmers/computer geeks and some other people are going to be R users (that just use R for doing stats, and inside here you can have veeery different levels). So, if you try to teach GIT, Github, R programming, Python programming, Markdown, software development workflow, unit tests... half of the people will be bored (if you just explain the basics) and half of the people will have a brain explosion :-)

If the objective of this course is to teach basics, the prerequisite should be basic programming in R or Python, and you can explain the reasons for using version control, GIT, how to share your code and work in teams with github, Markdown, etc. If you want to go further, I would suggest GIT as a prerequisite (basic commands in the command line/shell).

best,

Sara

[wking]

On Fri, Apr 17, 2015 at 09:44:55AM -0700, Sara Varela wrote:

I do not think people will be "afraid" if you set some prerequisites for this course. I think it is realistic.

See folks commenting on “imposter syndrome” earlier in this issue and in the mentoring@ thread (e.g. 1).

If you do not set any prerequisite you will end up with an heterogeneous group of people…

But I think we do want a heterogeneous group of instructors, including both master Git users and near-novice Python users. Not every instructor is going to be a perfect match for every audience (it takes a lot of skill to teach a group of folks with a skill-set much different than yours if you haven't taught similar groups many times before), but that's ok. Having a heterogeneous mix all crammed into one training course makes things a bit trickier, but (and maybe this ties into #514?) you can always let the bored folks opt out of sections where they already know the material, and if the training was more asynchronous that self-selection gets very efficient.

Opt-outs may make it harder to assess trainee knowledge during/after training (do we do this?), which seems like it would be important to a useful badging system. Anyhow, that's an assessment issue, and is independent from prerequisites.

[naupaka]

I am quite late to this discussion, but just wanted to contribute my experience. I knew nothing of git when I started instructor training several years ago. I learned git and GitHub via the instructor training and through collaborative repo work to set up for the first workshop I helped teach (where I taught shell and R). I now feel quite comfortable with git, but it is all due to the 'on-the-job' experience I have gotten as a SWC instructor, and then taking the skills I learned there back into my own research (currently a postdoc). So I would be in favor of not having a hard or even a soft requirement for instructors to know everything in the novice lessons before they start, as long as they feel quite confident in at least 1 or 2. All workshops have at least 2 instructors, so as long as the other one has a complementary skill yet, it should be ok.

[matthew-brett]

I would guess (I am happy to be corrected) that it is not a fruitful experience being taught a subject by someone who does not know that subject reasonably well.

One large part of SWC is demystifying these tools. It is fairly easy for students to detect when the instructors are themselves still mystified, and this in turns leads to students getting the impression that it is not necessary to understand the material, in order to use it - which is surely the opposite of the impression SWC wants to convey.

Forgive me for not reading the whole thread, but presumably there is no-one who thinks that every instructor has to know all the topics? I feel strongly that the person teaching git, needs to understand it well, but it's surely not necessary for all the instructors to understand git well.

[hevronig]

From reading part of the thread, there is a dilemma where prerequisites may discourage some people from registering to the instructors training, I think that someone who is motivated enough to become an instructor, will not get easily intimidated by such prerequisites.

In my opinion, a person aspiring to become a SWC instructor, should take the time to at least go over the SWC Lessons page prior to the instructors training course, and be capable of completing these intro-level lessons to a large extent. Including Unix shell, version control, databases, and a programming language of choice.

[anelda]

What about running two levels of instructor training (or will this cause unnecessary divide again?)

1. One for the entry level trainer who may themself only be "two steps ahead of their learners [1]"
2. Another for more advanced people

Here is more information to support my suggestion for those who have time to read on ;)

Thinking of our situation in South Africa where we have 1 qualified SWC trainer, 1 currently enrolled in online training, and 3 enrolled for training commencing in June, I would love to be able to encourage many more people to get trained as instructors. I am not an instructor but hope to be one – in the meantime I will be organising workshops and assist where I can.

I believe that as SWC grows in our country (and elsewhere) we will have a rich collection of trainers varying in technical skill level, teaching experience, and subject expertise and this will allow us to really make a difference to the way research is done and ultimately to the world – diseases/health, food scarcity, engineering questions, arts, and everything else we care about.

My personal passion is to help people who traditionally have not been exposed to computers besides Word and Excel and who inherently believes they will never be able to code or talk to “geeks” (the imposter syndrome mentioned before). I believe this is the first place where SWC can make a huge difference in South Africa. I love this statement:

“You don’t need to be an expert programmer to take part: in fact, we prefer instructors who are only two steps ahead of their learners and can still remember what it’s like to find programming difficult and confusing. You do need to be enthusiastic and willing to volunteer to help teach others what you know, and also willing to abide by our code of conduct.” [1]

BUT... SWC can also make a huge difference in the world of people who taught themselves to code or are not currently using some of the best practices for scientific coding or even ones who are using best practices.

I think SWC is successful based on so many factors

1. The fact that it tries to understand how people learn and act on it
2. The various topics available
3. The great curriculums put together from various angles to provide a solid foundation for newcomers
4. The culture of knowledge sharing, tolerance of different views, discussion, mentorship
5. The community who collectively knows so much and together can (and is) change(ing) the world

Attending a workshop or participating in instructor training don’t only provide one with skills to teach or to code, but it provides you with an opportunity to be submerged in this community where you can explore new things – safely without the fear of rejection or ridicule. That is what I’d like our South African researchers to be exposed to, to learn from, and to embrace.

Maybe we don’t have to decide what instructors should look like, maybe we can create two tiers of instructor courses – beginners and advanced. The beginner instructors could look like the quote above. Advanced trainers can be more technically experienced to really take research coding to the next level. Of course advanced trainers may teach at either level as they wish.

At the moment I am teaching people to do “ls” and “less” (okay slightly exaggerated) and work through the R novice material and they’re loving it and we’re all learning and it’s safe. But I can’t teach them magic R stuff applied to their specific research questions. I can’t teach them crazy git/GitHub tricks but I can help them learn about why one should be aware of version control and help them set up their Git account. And I can empathise because I’m struggling too, but I can encourage them because I have learnt so much in the last 3 months. I can basically prep them to attend a workshop offered by someone more experienced. I can help them write bad code (going from not coding at all) so that they learn and appreciate it when someone teaches them to write good code.

Hadley Wickham @hadleywickham • 18h 18 hours ago The only way to write good code is to write tons of shitty code first. Feeling shame about bad code stops you from getting to good code [2]

The main problem I foresee is having the capacity to provide training for all the trainees who might be interested in becoming SWC instructors… (Stating the obvious here). So, I guess we need to formalise the instructor training in a way that we can get more people trained up do run instructor training if we want to expand even more.

[1] http://teaching.software-carpentry.org/page/2/ [2] https://twitter.com/hadleywickham/status/589068687669243905

[wking]

On Sat, Apr 18, 2015 at 01:35:23AM -0700, Anelda van der Walt wrote:

Maybe we don’t have to decide what instructors should look like, maybe we can create two tiers of instructor courses – beginners and advanced. The beginner instructors could look like the quote above. Advanced trainers can be more technically experienced to really take research coding to the next level. Of course advanced trainers may teach at either level as they wish.

I have two concerns with this approach:

1. There are a host of skill dimensions here, and it's hard to collapse that all down onto a single beginner↔advanced axis. Allowing folks to opt-out of a particular topic if they feel comfortable with it already 1 makes more sense to me than trying to pre-sort trainees into pre-defined tracks.
2. We don't actually use most of these skills (Python, shell, Git beyond basic PRs) in the current instructor training course 2, so while (self-)splitting trainees based on their existing knowledge of a skill they're learning makes sense, I see no reason to split them based on their knowledge of a skill they'll be teaching.

Since “Markdown and PRs via the GitHub web UI” is maybe a half-day of training 3, I think we should still put everyone through the same “how to teach in the SWC style” course, and just tell folks with existing Markdown/Git knowledge that they can show up after lunch and skip the Markdown/Git introduction (or skip the week that covers Markdown/Git, or whatever works for the way their course is structured, #514).

[iglpdc]

Wow, there is really a lot going on here. I'll be brief. I think that we should put some prerequisites, the prerequisites don't have to be hard-lined, and being an instructor is not for everyone. I elaborate now.

I think that to teach something you should have a relevant experience in the field. The more, the better. SWC assumes that there basic computational skills that scientists should have, such as automating tasks using the UNIX shell, version control, and basic concepts of programming. Note that these are not tool related, but mostly conceptual frameworks (i.e. why writing functions, and not which is the R syntax to write a function). I think the requirement should be have a intermediate knowledge of such concepts. This is specifically vague to accommodate all the different background we see in our current instructors and hard to assess and test, so I think it should be up to the future instructor to think if they have such knowledge.

To me the point is not dropping git or vi or markdown, it's whether the instructor is experienced enough in using the skills whose use we're advocating. Note that tools may change. A couple of years ago, SWC used SVN instead of Git, there was no sign of R or MATLAB, Markdown wasn't a thing, and we had lessons on spreadsheets. I particularly struggle with git sometimes, because I use mostly SVN for work. But I started using version control almost 10 years ago, so I understand why and how to use it and can make a case on a workshop on why scientists should do it. Same goes for programming. I don't use R, but I can explain the R materials on loops or functions at a novice level if I have some notes on the R syntax, because I have experience programming on other languages.

I think instructor training was designed to instruct scientists with relevant experience on computing [1] how teach to others, and that's why there's almost no emphasis on actual materials we teach. Our prospective instructors are changing now and we're getting people without this experience we took for granted.

My solution would be ask the prospective instructors to go thru our novice lessons and assess if they would feel comfortable teaching them, even if they don't know the particular tool. I don't care if someone has trouble doing pull requests for a few times, but if they never used the command line or a text editor before, I don't think they would be prepared to teach SWC after the instructor training nor that we should change the training curriculum to fit them.

[1] And I think this sentence is important: scientists who understand the issues other scientists are facing, who probably don't have a proper CS training, but learnt in the trenches, and whose computing skills may not be consider such in a broader CS or software development context.

[wking]

On Mon, Apr 20, 2015 at 09:09:08AM -0700, Ivan Gonzalez wrote:

My solution would be ask the prospective instructors to go thru our novice lessons and assess if they would feel comfortable teaching them, even if they don't know the particular tool. I don't care if someone has trouble doing pull requests for a few times, but if they never used the command line or a text editor before, I don't think they would be prepared to teach SWC after the instructor training nor that we should change the training curriculum to fit them.

I think this is a reasonble position, but:

1. Some folks are going to have trouble assessing themselves (imposter syndrom, and whatever the “yeah, I'm and expert in $THING_I_HEARD_ABOUT_YESTERDAY” inverse is called ;).
2. There's no need to (self-)filter incoming trainees if we have sufficient instructor-training capacity. We can just put any interested party through the “how to teach” course, and let them work on the “what to teach” material afterward 1.

So far, I haven't heard about any issues with our training capacity, so I think it's best to err on the side of inclusion to avoid issues with self-assessment.

[luispedro]

Some folks are going to have trouble assessing themselves (imposter syndrom, and whatever the “yeah, I'm and expert in $THING_I_HEARD_ABOUT_YESTERDAY” inverse is called ;).

This is another reason why words like "novice" or "expert" are so useless (even "two steps ahead of the learners" is useless). However, "can you do a PR on a github repo?" is a very useful question.

If there is no input filter, do you propose an output one, like an exam before people can be certified? Otherwise, how can you ensure that the certification represents something?

So far, I haven't heard about any issues with our training capacity, so I think it's best to err on the side of inclusion to avoid issues with self-assessment.

http://swcarpentry.github.io/training-course/ says Our online courses are full for the remainder of 2015. Please complete this form if you would like to be added to the waiting list for 2016.

I have heard of courses filling out very very fast.

[wking]

On Mon, Apr 20, 2015 at 10:11:54AM -0700, Luis Pedro Coelho wrote:

If there is no input filter, do you propose an output one, like an exam before people can be certified? Otherwise, how can you ensure that the certification represents something?

We currently have neither filter as far as I know, other than “you need to submit (and maybe land) a PR against a lesson after you finish the course” (although I don't know where that's laid out). Then we have a joint-teaching at the first workshop with a more experienced instructor. My guess is the current quality control is that more experienced instructor, who suggest de-badging if the new instructor completely bombs (or something like that?). I don't know that this has been figured out yet, but I think some kind of subjective assessment of teaching quality is probably the best we'll be able to do in the short term.

So far, I haven't heard about any issues with our training capacity, so I think it's best to err on the side of inclusion to avoid issues with self-assessment.

http://swcarpentry.github.io/training-course/ says Our online courses are full for the remainder of 2015. Please complete this form if you would like to be added to the waiting list for 2016.

I have heard of courses filling out very very fast.

Thanks for the links :). Maybe we want to revisit the “no prereqs” approach 1 in light of this bottleneck? On the other hand, we want to maintain instructor diversity 2 and self-selection is a homogenizing influence. Is it worth shifting “submitted a PR against a lesson” from a post-test to a pre-test? That would shift our trainee bias from the current “folks who are patient enough to wait for a slot” to “folks who know enough Git to submit a PR, and can read the lessons critically enough to find an improvement”.

[matthew-brett]

Am I right in thinking that the current emphasis on teaching 'how to teach' is partly based on the assumption that people already know the material for 'what to teach'?

For example, if you were teaching calculus, and your teachers didn't know calculus, you would have to teach that - first - or as well.

There must be some danger in expanding software carpentry to the degree where the instructors do not themselves know the material. It's possible that will just improve the coverage of SWC, but it's also possible it will affect the reputation of SWC enough to slow the current progress.

[wking]

On Mon, Apr 20, 2015 at 10:27:45AM -0700, Matthew Brett wrote:

There must be some danger in expanding software carpentry to the degree where the instructors do not themselves know the material.

One of the problems is that “what to teach” is pretty flexible ;). Although we could probably swing requiring some sort of demonstrable competence in our core lessons: the POSIX shell, structured programming (in Python, R, Matlab, …), and version control (Git, Mercurial, …) 1. I don't know how we'd test that competence (submitting a PR on GitHub just checks one of the optional tool choices), but I'd be interested if someone better at assessment had some ideas there. And requiring some competence in all three subjects seems like a big enough shift that I think we'd want to ease into it and see how it affected our trainee pipeline before committing completely. I think “we want a Git (or Mercurial) PR before training” is a big enough first step, if we do want to go the prereq route 2.

[wking]

On Mon, Apr 20, 2015 at 10:39:53AM -0700, W. Trevor King wrote:

And requiring some competence in all three subjects seems like a big enough shift that I think we'd want to ease into it and see how it affected our trainee pipeline before committing completely.

If we have more students than we can teach, pre-testing would be a reasonable way to define multiple pipelines. Instead of having multiple tracks after folks are accepted 1, we could have:

• A no-prereq queue, for folks who lack (or think they lack) the necessary skills. All you need is the patience to wait in the queue until we have a slot to put you into the no-prereq course (where Markdown and Git are explicitly taught).
• A Markdown/Git-proficient queue, for folks who land a PR in one of our lesson repositories. Folks who show enough commitment and skill to get this done get to enter the shorter queue.

Then potential trainees can decide how to balance the cost of a longer wait vs. the cost of self-teaching Git/Markdown (with help@ and our Git lesson as resources). And the SWC admins can balance diversity by modulating the weighting between pulls from either queue (so long as the no-prereq queue doesn't get shorter than the prereq queue ;). This scales well if we turn out to need finer controls, since you could require landed PRs in three core lessons (shell, Python/R/…, and Git/Mercurial/…) to get into an even shorter queue, etc., etc.

I think this would work well for online courses, but you'd need a bit of lead time (to give folks time to write and land PRs) if you wanted to use it for on-site courses.

[matthew-brett]

It seems to me that git is a particularly good example of a topic that can be badly taught by someone who does not understand the underlying model. That can have a bad effect on the students, because they can't help but come away thinking that git is used by an obscure set of magical incantations, setting them on entirely the wrong path for their future learning.

[wking]

On Mon, Apr 20, 2015 at 11:03:05AM -0700, Matthew Brett wrote:

It seems to me that git is a particularly good example of a topic that can be badly taught by someone who does not understand the underlying model.

But you can be a perfectly competent SWC instructor, leading workshops entirely by yourself, etc., etc., if you only know Mercurial and have no Git knowledge at all. Since the SWC label only requires Git or Mercurial 1.

And really, I think all of our tools (and probably most subjects) are like that. You need enough of a grasp of the subject that when learners get the wrong idea you (a) notice and (b) can lead them back to the truth in a short, enlightening manner. Having both experienced instructors/helpers present (for that sort of thing) and less experienced instructors/helpers present (for “you can do this without being a wizard” moral support) is ideal.

[iglpdc]

To me, the PR on Github is anecdotal and should not be a requirement. I can do a significant PR fixing typos or rewording text using mostly (maybe only?) the Github web interface. This doesn't test my knowledge of the skills we aim to teach (automation, structure programming, and version control). Furthermore, Git is pretty young (at least its widespread use) and same goes for Markdown. A better test to me is using the shell and other command line tools. If someone is confident writing programs in whatever language using only command line tools, he/she could learn the specific tools we teach.

[matthew-brett]

@wking - sure - I am certainly not arguing that you should understand the git model before you teach some other topic, such as shell, markdown or structured programming.

But I am arguing that, if you haven't read about and understood the git underlying model, you will be very likely to lead the students down the wrong path - when teaching git. It's one obvious case where understanding some basic ideas does have a large impact on how you teach.

[weaverbel]

In my original response to this issue, I wrote

I honestly think the most important attributes for Software Carpentry instructors are

(a) a strong desire/motivation to help researchers pick up important skills (b) the ability to see the problems learners have from the learners' own perspectives.

Having now almost completed instructor training, and being about to run a bootcamp, I would now add a third, namely

(c) the willingness to learn the lesson content well enough to be able to teach it.

That means learning to use Git, the shell, Python, and so on even if they seem hard or incomprehensible at first.

When I started instructor training, I could not have taught the lessons. But I got a Linux laptop, worked through the lessons, did the homework tasks, and now I feel I could teach some of the lessons, which is a huge step forward. Obviously I still have a way to go but I was more than willing to engage with a whole raft of new material. If we are to keep training instructors without strong technical backgrounds, they need to demonstrate that same willingness to learn.

[iglpdc]

Well, I think knowing the materials well enough to be able to teach them is pretty much is the least one could ask for an instructor, in any case, not only for SWC. But the point is not that, the point is what we should ask from someone before becoming an instructor.

I cannot understand the motivation of someone deciding to become an instructor in something far from his/her background or current skills. I'd recommend this person to take our regular bootcamp, learn the basics, get some practice, and take the instructor training later. I think it's common sense.

In our mission statement [1], I see we are dedicated "to improve basic computing skills of researchers" and that "we want a significant fraction of our learners to become instructors". To me this means that future instructors must have at least the equivalent technical knowledge of learners at the end of our bootcamp.

[1] https://software-carpentry.org/scf/index.html

[huguesfontenelle]

Prerequisite: having attended a workshop as a helper.

No particular pedagogic skills need besides some guidelines those offered by whomever runs the workshop. Some technical skills obviously needed to be useful, also decided by the local team.

[iglpdc]

Prerequisite: having attended a workshop as a helper.

@huguesfontenelle, this works if you leave in the Bay area or NYC, where we have a bunch of workshops and opportunities to help abound. Helpers are not reimbursed for travel, so how a person from Brazil, Spain, or Namibia is gonna find opportunities to attend as a helper and become an instructor?