Teaching basic lab skills
for research computing

Teaching at the Board

This post originally appeared on Chris Hamm’s personal blog.

Software Carpentry is a non-profit organization that teaches basic computer skills. The lessons for these courses assume no prior knowledge among the learners. I am a certified instructor for Software Carpentry and its sister organization, Data Carpentry.

I have taught two Software Carpentry workshops at the Federal Reserve Board in Washington, DC and they were very different from one another. Both workshops were successful but for very different reasons. This post explores the reasons why (I think) they were so different.

The first course was held in late June and the learners were all relatively new employees and the level of lessons (shell, R, git, and more R) was appropriate for their skill level. The students were engaged, followed the materials, and it was an excellent workshop.

The second course was held in late August and the learners for this workshop were all seasoned employees that had worked at the Fed for 2-3 years. After only 30 minutes into my R lesson I could tell that I did not have the students. I’ve taught this lesson ~10 times for Software Carpentry, I know the material very well and consider myself a good teacher. This was the first time I did not have any questions or learners in need of assistance. Something was up.

I called an audible. I paused the lesson and started a discussion with the students to understand why the lesson was falling flat.

The learners conveyed that they were all experienced with R and that this material we far too simple for them. Yet, their level of expertise was above that of Software Carpentry lessons.

My co-instructor and I decided to alter the lessons so the learners could get something out of the course. I ditched the basic R lesson and went into more data manipulation, installing packages from source, interfacing R and SQLite, using the ProjectTemplate package and how RStudio integrates with git. My co-instructor changed her materials to focus more on data manipulation via the shell.

We were lucky to be able to make adjustments and come up with new lessons, but this is not and should not be the standard for Software Carpentry lessons.

It is important for potential leaners to recognize that we teach basic computer skills and to read workshop descriptions before signing up.

Sticky notes (the learners write something that we could improve on and something that worked well for them) from my lessons are below:

Intro to R

Worked well:

  • Thanks for noticing & adjusting to the level of the class: interested in for tomorrow: call stack, tidyr, split-apply-combine, vectorization
  • I really enjoyed the small SQLite tutorial / everything was very clearly explained
  • awesome explanation and super fun problem solving
  • good changes at end
  • loved interactive instruction
  • I really benefited from doing exercises. It’s helpful to try things out yourself.

Needs work:

  • Too basic at first (but got better!)


Worked well:

  • Really liked going through ProjectTemplate w/git. I’m at the point in code, etc., where I’m thinking a lot more about organization etc. Although it was a little bumpy it wasn’t bad at all. On your own you run into errors and it was valuable to learn how to remedy them.
  • Thanks for coming. I liked the shell parts & git
  • Overall, I’m very glad I took the course. I’ll definitely adopt the RStudio, git, ProjectTemplate workflow.
  • Great interaction / response to feedback from Day 1. very useful. having never used git, step by step
  • Good git stuff, found it very helpful
  • explanation of git basics were great, the repetition of commands was nice
  • the git / unix classes are great. Very helpful.

Needs work:

  • Git demo became repetitive in the middle
  • I might start with git and RStudio, then move to git in Linux because there are more visual clues to whats going on in RStudio
  • More of a “Fed Board” problem but it would’ve been cool to work with the repositories already created in my section
  • Why can’t we start at 9
  • Dimming the lights might make it easier to see the big screen. Thank you.
  • Slow down the lecture please
  • No complaints

Dialogue & Discussion

You can review our commenting policy here.