… in no particular order, these are the elements
These are recursive notes of organising any carpentries workshop. We will use some of these in our own instructor training processes, but the elements are all there. Some of the concepts are annotated
Start the day of the instruction by going to the venue at least 30 minutes ahead of time
Needed to set up the site. In the site itself try to troubleshoot for the participants. Our aim will be that, each participant should leave the workshop with a set of computer programmes that he or she can use in productive work as well.
We teach computational competence and computational thinking much less specific skills
This is the key point. Our aim in the software or data carpentry workshop is to make sure each participant has ample time to practice and has opportunities of his or her questions answered. Similarly, in the instructor training workshop, each participant should at least have a solid understanding of the
- key pedagogical issues
- proficient with live coding
- learn to set up a workshop
Dress professionally and speak well about yourself
The need to speak well about yourself is to make sure that we do not succumb to the impostor syndrome. Impostor syndrome is the phenomenon where even though X is an expert or knowledgable about a particular topic, X has a fear that he or she does not know enough about the topic or he is a novice and people will find out. This is a particular issue with women and minorities who are experts in particular topics. Such fear or apprehension has no foundation; an instructor should not suffer from this phenomenon.
The opposite of impostor syndrome is Dunning Kruger phenomenon. In this phenomenon, a person who does not know about a subject S pretends that he knows more than he actually knows.
Create learner persona
Before starting to plan a course, set up learner persona. This is important to target pitching to the right audience. A good idea is to get a sense of what people know or do not know about the topic that you want to teach. Get a sense of who will take your course and what they may know or what content knowledge they will arrive at your instruction.
Novices, competent practitioners, and experts
In carpentries, our goal is to start with novices and move them to the stage of competent practitioners. We can have people who enter our courses in different stages. The following table defines the three types of learner persona:
| Persona | Does not know | Knows |
| Does not know | Novice | Expert |
| Knows | Competent Practitioner | Guru |
A novice does not know what he does not know. A novice does not even know the right questions to ask. For example, consider a newcomer who is a novice in R. A novice would not even know what questions to ask about writing a function in the first place. A competent practitioner knows his limitations or is aware what he is not knowledgable about or his limitations; but a competent practitioner can generally solve a problem or provide a solution to most issues on a daily basis. An expert may not even know what he knows and that can often lead to expert blind spots. So while an expert is good at doing research, because an expert has issues around not being cognizant of what he knows or not being cognizant of the intermediate steps, he often skips steps that are necessary for a beginner or a novice or even a first stage competent practitioner to make sense of the world.
The expert also has what is often referred to as ‘fluid representation’. Fluid representation refers to the phenomenon that experts often skip intermediate steps in their reasoning and move straight to the solution where novices and non-experts continue to search for answers or use the steps.
Experts and competent practitioners also differ from novices in their mental models. Mental model refers to a network of ideas and concepts and facts that make up the knowledge content that people have and their inter-relationships. An expert or a competent practitioner or even a novice in a subject may have similar amount of contents, but the density of connections and richness of the interconnections between the individual nodes are highest among the experts and very sparse among the novices.
People also often have issues about misunderstandings of topics. In general, these can be classified as follows:
- Factual misunderstanding: these can be corrected by providing accurate facts
- Flawed mental models that are due to wrong perceptions. These are issues that can be corrected with reinforcement of correct mental models
- Wrong or false beliefs: these are the ones that are hardest to correct
In general, the aim will be reinforce mental models. The path to build robust mental models is NOT to repeat the same practice over and over again, but to repeatedly do similar things and challenges that are _slightly_ different each time.
Draw concept maps to construct a lesson
A concept map is a tool to identify the mental model of an individual. A concept map consists of the following:
- A number of nodes that are worded as nouns or adjectives
- Nodes are connected with edges (directed edges) that are represented with verbs or action words
- More abstract concepts or more general concepts are at the top of the page
- More and more concrete concepts are placed in the bottom of the page
- Draw concept maps using paper and pencil rather than software tools although cmap software is a great tool to draw concept maps on any topic
Participatory live coding
Carpentry lessons are best imparted using participatory live coding. This is based on the philosophy that ‘typos are the pedagogy’ so that errors, instead of accepting them as ‘faults’, they are positively framed and used as opportunities to learn for learners and to push specific teaching points. This is best used in shared coding where the teacher starts writing codes and the students follow suit in emulating the teacher to write codes on their own machines as well. As the teacher writes codes, the teacher explains each word, or each action in details. The teacher slows down as he writes the codes and this allows the learners to repeat writing the codes on their own machines and execute them and when needed, ask questions. The following rules are conventionally adopted for participatory live coding:
- Stand up and deliver the lesson
- Speak and type very slowly
- Explain each step as you write the codes
- Once the code shows up on the screen, take extra time to explain each line of the code
- Invite questions from the students by repeatedly asking, “What questions do you have?”
Use formative assessments roughly once every 15 minutes
Formative assessments refer to an assessment policy where the teacher uses multiple choice questions to tap into what the students have learned or what the students have misunderstood. Multiple choice questions with one correct answer and two to four distractors with common errors are the best format. This helps the teacher to either move on and introduce a new idea or stop and explain the common misunderstanding to the students.
Use multiple formats of assessments
Other than MCQs, you can use other formats. Two common formats are:
- Faded examples: Here, for example, you start with a worked out example of a problem and a solution. Then progressively, remove one step of the solution and ask the students to fill in the missing bit. You increase the level of difficulty subsequent and in steps.
- Parsons’ Problem: here, present the solution but jumble up the sequence. Let the students figure out the best order of finding the solution
- Think-pair-share: Have two students share the computer and one of them solves or works on the computer while the other observes. Pose a challenge and ask both of them to ‘brainstorm’ ideas or correct answer and then debrief.