Software Carpentry

-- Slide --

Software Carpentry: an overview

NB NeCTAR Cloud Starter training is not a Software Carpentry course.

-- Slide End --

If you are going to understand our material and contribute back you need to know a little about Software Carpentry.

History

Software carpentry grew from the realization that researchers need to install and maintain software: not only that - they need to occasionally write, debug and test it as well. Yet most researchers are not taught to do this!

A course to tackle this problem was developed and run by Greg Wilson and Brent Gorda in 1998.

From the delivery of this course they learnt that:

-- Slide --

Lesson 1

  • Week long courses frazzle the attendees brains
  • Textbook SLDC1 is not useful to researchers

1: Software Development Life Cycle

-- Slide End --

Observation A day of the cloud starter training leaves people feeling frazzled!

Subsequent to this the course materials were put on line. Other iterations followed.

During this period it was realized that:

-- Slide --

Lesson 2

  • Most computer scientists don't have an interest in training researchers
  • The target market is new postgraduates

-- Slide End --

MOOC style courses were also attempted.

-- Slide --

Who's done a MOOC1?

  • G = Yes!
  • R = No: why would I?

1: Massive Open Online Courses

-- Slide End --

-- Slide --

Who's finished all the MOOC's they have started?

  • G = Yes!
  • R = Life. Just keeps on interfering :(

-- Slide End --

From this came the realization:

-- Slide --

Lesson 3: MOOCs!

  • Video's are a huge amount of effort
  • Most people don't complete the courses

-- Slide End --

How learning works

The team behind Software Carpentry constantly attempt to incorporate and build the findings of current research on learning into their material.

So how do we learn?

-- Slide --

Analogies

Students learn new ideas by building on what they know.

-- Slide End --

This can be both a help and a hindrance.

A help if their existing knowledge is good. A hindrance otherwise.

So our material tries to:

  • Use analogies that students are likely to understand
  • Introduce concepts in sequence, building on what has gone before

-- Slide --

Memory

From Working -> Long Term

-- Slide End --

Working memory has very limited capacity.

So our material:

  • Uses scaffolding to reduce cognitive overload
  • But gradually removes the scaffolding
  • And should be well paced

-- Slide --

Where did I put my keys?

What goes into memory often vanishes almost straight away

-- Slide End --

We address this by

  • Asking questions
  • Telling stories
  • If needed, we can introduce mnemonics (we haven't needed to yet)
  • Repetition giving practice

-- Slide --

Practice is good

But not all practice is equivalent.

-- Slide End --

  • Spaced practice is good
  • Quizzes help
  • Interleaving practice is more effective

-- Slide --

Feedback is needed

And it should be:

  • Specific
  • Clear
  • Focused on the task
  • Explanatory

-- Slide End --

All of this is the inverse of http://www.barbaraoakley.com/pdf/10rulesofstudying.pdf, really.

So after years of effort, review, and development, Software Carpentry now has the following format:

-- Slide --

Format

  • A two day workshop
  • Covering a small set of tools
  • That introduce high level concepts
  • With the goal of teaching computational competence

-- Slide End --

The following guidelines are in place

-- Slide --

Guidelines

  • No more than 40 people in a workshop
  • If possible, parallel sessions, with attendees streamed by ability

If parallel sessions are run, then:

  • A pre-assessment questionnaire is used to create the groups
  • People are not swapped from group to group

-- Slide End --

The workshops aim to have:

-- Slide --

Staffing

  • An instructor up front
  • At least 1 roaming helper per 8 attendees

-- Slide End --

Observation We have found that the more helpers we have the smoother the day!

Feedback

Extensive use is made of feedback loops.

-- Slide --

Feedback loops

  • Sticky notes
  • Minute cards
  • Summary feedback
  • Post workshop assessments

-- Slide End --

Sticky notes are handed out to learners:

  • two different colours (typically, Red and Green)
  • used for true/false answers
  • to show pain if not not coping
  • and to signal that activities are completed

Minute cards:

Before each break the learners are asked to write one thing:

  • that they've learnt on their green sticky note
  • that they found confusing on their red sticky note

The instructor then collates these and incorporates the feedback into the next iteration of the lessons.

Summary feedback at the end of the day:

Every attendee is asked to stand and to give one good point about the day, and one negative point, without repeating what has already been said. The instructor makes notes and incorporates the feedback into the next iteration.

Post workshop assessments:

After the workshop an assessment is sent to the attendees.

Observation These don't have high return rates.

Instructors are also requested to provide feedback in debriefing sessions.

-- Slide --

We really like

  • Multiple choice questions

-- Slide End --

We find that not only do they help us with seeing if the students understand the material, they also act as punctuation marks in the lessons that engage the students.

We have found it really hard to design good questions, though...

-- Slide --

Delivery

  • Live coding
  • Two devices for the instructor
  • An Etherpad session
  • Learners work on their own machines
  • Pair programming (so dinner table style rooms over lecture theaters)

-- Slide End --

Live coding because it is good to demonstrate to the learners that experts make mistakes.

Two devices: one for the lesson plan, and one for the overhead projector.

Etherpads help to share links and also do encourage engagement between the students.

Observation Pair programming: we only use this if people have trouble logging on or don't have their own computers.

Observation We find it really good if the instructor leaves the podium and wanders around during the exercises. This stops the students from focusing on the front of the class. There seems to be some kind of weird leadership thing in play?

-- Slide --

SWC: biggest challenges

  • Are they truly helping researchers?
  • Diversity of learners - 20% bored, 20% lost :(
  • People don't contribute back...

-- Slide End --

Observation We have the diversity of learners, but we don't suffer the problem of boredom.

So

Software carpentry has been under continuous iterative development for many years now. Along the way the material has been reworked to take into account the latest in educational research and feedback from the actual delivery.

BTW, Software Carpentry material is licenced under a creative commons licence. Anyone is free to use it.

NB But you are not free to use their name and logo! There are strict conditions applied to this. They want to maintain their good name and reputation!

We feel that if you haven't done it yet, that you should sign up for their trainers course!

-- Slide --

Subscribe!

If you are going to be doing a lot of SW Carpentry style training consider subscribing...

-- Slide End --

I'm going to intersperse today with some of the interesting things we've learnt from Software Carpentry. So:

-- Slide --

True or False: People have different learning styles

  • G = True.
  • R = False.

-- Slide End --

A False - it's true that we have preferred learning styles. But our preferred learning style is probably not be our best learning style...

Further, learning styles are typically given a granular nature and labelled ("Visual!", "Auditory"), but us humans actually form a continuum. Preparing lessons for a label short changes the continuum.

results matching ""

    No results matching ""