Software Carpentry
|
As a certified Software Carpentry Instructor, I teach researchers in science and engineering best practices for scientific computing by live-coding in a two-day, learner-centered workshop. Recent workshop: January 2018, UW-Madison Learn more: Software Carpentry Foundation |
Involvement
2018
January: Voting member of Software Carpentry
January: Shell Instructor, Software Carpentry Workshop [workshop page] [student feedback]
2017
June: Shell Instructor, Software Carpentry Workshop [workshop page] [student feedback]
January: Certified as a Software Carpentry Instructor [SWC team page]
January: Helper, Software Carpentry Workshop [workshop page]
2016
October: Learner, Software Carpentry Instructor Training
June: Learner, Software Carpentry Workshop
January: Voting member of Software Carpentry
January: Shell Instructor, Software Carpentry Workshop [workshop page] [student feedback]
2017
June: Shell Instructor, Software Carpentry Workshop [workshop page] [student feedback]
January: Certified as a Software Carpentry Instructor [SWC team page]
January: Helper, Software Carpentry Workshop [workshop page]
2016
October: Learner, Software Carpentry Instructor Training
June: Learner, Software Carpentry Workshop
Reflection
This reflection is structured around the Delta Pillars. For more on these core principles, see overviews by the UW-Madison Delta Program or the national Center for Integration for Research Teaching and Learning (CIRTL).
Teaching-as-Research
Ever since I became involved with Software Carpentry, our local UW-Madison community has been searching for a way to offer post-workshop support to learners. We are challenged by the paradox that learners want and need more support than we can provide in 2 days (they tell us this on post-it note feedback during the workshops), but they find it hard to dedicate additional time to this non-immediate need. In the time I have been involved, we have tried....
Hypothesis #1: Give them the opportunity they are clamoring for, and learners will take advantage of it.
Strategy: Open office hours with instructors about 1 week after the workshop.
Successful if: A half-dozen learners come by
Result: No one shows.
Possible explanations: Perhaps it's too open ended? No one has questions that are urgent enough to show up in person that soon after the workshop?
Hypothesis #2: Focus on virtual, on-demand support, and learners will use it to get just-in-time help
Strategy: A new listserv where attendees can post coding questions, to be answered by anyone in the UW-Madison Carpentries community
Successful if: There are 1-2 email queries per month
Result: There are 2 queries in the first year, one of which is more of a "write my script for me" request than we were hoping for.
Possible explanations: People forget that the resource is there? It feels like a higher bar to type out an email question than to raise an issue in-person?
Hypothesis #3: Semi-structured follow-up sessions will draw learners back for the lesson, and provide the benefit of in-person help
Strategy: Follow-up sessions with 15 minutes of scheduled lesson, followed by open time for questions.
Successful if: A half-dozen learners come by.
Result: 2 people show.
Possible explanations: Structure helps, but it's too easy to be distracted by other problems-of-the-moment when it's just a "would be nice" item on your calendar?
Hypothesis #4: Requesting commitment from learners interested in follow-up sessions will encourage more to show up
Strategy: Request that learners register (for free) for semi-structured follow-up sessions through the same system they used to register for the workshops
Successful if: A half-dozen learners come by
Result: 6 sign up, 5 show for Shell! Follow-ups for other topics ongoing...
I am grateful to be part of an all-volunteer, teaching community that values Teaching-as-Research at the local level just as much as it does at the foundation level.
Hypothesis #1: Give them the opportunity they are clamoring for, and learners will take advantage of it.
Strategy: Open office hours with instructors about 1 week after the workshop.
Successful if: A half-dozen learners come by
Result: No one shows.
Possible explanations: Perhaps it's too open ended? No one has questions that are urgent enough to show up in person that soon after the workshop?
Hypothesis #2: Focus on virtual, on-demand support, and learners will use it to get just-in-time help
Strategy: A new listserv where attendees can post coding questions, to be answered by anyone in the UW-Madison Carpentries community
Successful if: There are 1-2 email queries per month
Result: There are 2 queries in the first year, one of which is more of a "write my script for me" request than we were hoping for.
Possible explanations: People forget that the resource is there? It feels like a higher bar to type out an email question than to raise an issue in-person?
Hypothesis #3: Semi-structured follow-up sessions will draw learners back for the lesson, and provide the benefit of in-person help
Strategy: Follow-up sessions with 15 minutes of scheduled lesson, followed by open time for questions.
Successful if: A half-dozen learners come by.
Result: 2 people show.
Possible explanations: Structure helps, but it's too easy to be distracted by other problems-of-the-moment when it's just a "would be nice" item on your calendar?
Hypothesis #4: Requesting commitment from learners interested in follow-up sessions will encourage more to show up
Strategy: Request that learners register (for free) for semi-structured follow-up sessions through the same system they used to register for the workshops
Successful if: A half-dozen learners come by
Result: 6 sign up, 5 show for Shell! Follow-ups for other topics ongoing...
I am grateful to be part of an all-volunteer, teaching community that values Teaching-as-Research at the local level just as much as it does at the foundation level.
Learning Through Diversity
When you attend a Software Carpentry Workshop, it might be in any of 35 countries around the world, in English or Spanish. Learners may be undergrads, grad students, postdocs, research staff, or faculty. Their research home might be in biochemistry, ecology, library science, or engineering, just to name a few. And their experience varies too - some learners are acquainted with RStudio but afraid to run anything in the shell, while others run models remotely on high throughput machines and are just a little unsure of how to use git for version control.
Partly because of this, we as instructors prioritize creating an inclusive environment. We assure learners: it's ok if you don't master everything today. We'll send you home with reference sheets, a collaborative notes document, the lessons themselves, and the email for a listerv where any instructor or helper can respond to your questions. Falling behind during the workshop? Raise your hand - the instructor will call on you. Or ask your neighbor - you got to know them at the start of the workshop. Or tilt your green & red nametag to the red side - a helper will be at your side shortly. Or ask a question in our collaborative etherpad - we'll answer it there.
Most importantly, we draw on the diverse experiences of our fellow learners, helpers, and instructors to make the workshop even richer. All of our instructors have a favorite text editor that is best suited for their research and their work style - we share our winners, roundtable style. Some of our learners are pros at one of the three lessons and don't need to devote their full attention to it - they take notes in our collaborative etherpad for other learners to refer to later. There are windows, mac, and linux users in every workshop - we crowdsource troubleshooting tips whenever something surprising happens in one of the operating systems.
More than any other experience I've had, Software Carpentry has demonstrated for me how much more powerful learning can be when diversity is embraced as an asset.
Partly because of this, we as instructors prioritize creating an inclusive environment. We assure learners: it's ok if you don't master everything today. We'll send you home with reference sheets, a collaborative notes document, the lessons themselves, and the email for a listerv where any instructor or helper can respond to your questions. Falling behind during the workshop? Raise your hand - the instructor will call on you. Or ask your neighbor - you got to know them at the start of the workshop. Or tilt your green & red nametag to the red side - a helper will be at your side shortly. Or ask a question in our collaborative etherpad - we'll answer it there.
Most importantly, we draw on the diverse experiences of our fellow learners, helpers, and instructors to make the workshop even richer. All of our instructors have a favorite text editor that is best suited for their research and their work style - we share our winners, roundtable style. Some of our learners are pros at one of the three lessons and don't need to devote their full attention to it - they take notes in our collaborative etherpad for other learners to refer to later. There are windows, mac, and linux users in every workshop - we crowdsource troubleshooting tips whenever something surprising happens in one of the operating systems.
More than any other experience I've had, Software Carpentry has demonstrated for me how much more powerful learning can be when diversity is embraced as an asset.
Learning Communities
It was not until I reflected on learning communities for my Delta Internship proposal that it occurred to me: I was 4 years into my PhD and I could only think of one or two learning communities to which I belonged. More critically, I could not think of any I was a part of that related to the technically challenging parts of my research. While taking Instructor Training for Software Carpentry later that semester, it struck me: this was it! Software Carpentry is exactly the type of inclusive group with shared learning goals and diverse backgrounds that defines a learning community. All of the instructors I know are passionate about sharing their expertise in coding best practices with all who are interested. I have learned at least as much - if not more - about software best practices as an instructor in this community as I did when I was officially a workshop "learner". I feel both challenged and welcomed as part of the Software Carpentry Foundation, and because of that I prioritize being an active community member.
I do sometimes wonder why it took me so long to realize that I was missing the support of learning communities in my graduate student experience. My best guess is I simply didn't have the language or grounding in literature to realize it was something I wanted or needed. Sometimes you don't know what you don't know....and in my case it wasn't until I was asked to explain how I fostered learning communities for my students that I realized I was failing to develop them for myself.
I do sometimes wonder why it took me so long to realize that I was missing the support of learning communities in my graduate student experience. My best guess is I simply didn't have the language or grounding in literature to realize it was something I wanted or needed. Sometimes you don't know what you don't know....and in my case it wasn't until I was asked to explain how I fostered learning communities for my students that I realized I was failing to develop them for myself.
