Add time estimates to novice teaching materials

[jdblischak]

Currently the information for teaching the novice materials are contained in novice/teaching and the README files in individual directories, e.g. the shell README. One notable absence in this documentation is time estimates for teaching the material.

tl;dr I propose we add time estimates for each lesson in its appropriate README file.

The current sample homepage allocates about 2 hours and 45 minutes (assuming a 15 minute coffee break) each for the Unix Shell, Git, Python, and SQL. However, I suspect this fast rate is not practical for many novice bootcamps where the attendees have little to no prior experience programming. As a recent example, @rbeagrie explains in a blog post that they were only able to teach 5 of the 6 Python lessons and had to completely skip SQL. I too have had similar issues trying to cover too much in only two days and know that many others have as well. This practical knowledge of how much can realistically be taught over two days needs to be better transmitted to all new instructors. Furthermore, it is often asked for, e.g. this recent post from Josh Adelman on the discuss list.

I think it would be ideal to have a time range for each individual lesson in the README in its subdirectory. The low end of the time estimate would be for teaching more advanced attendees and the high end would be the time needed for teaching complete novices.

[chendaniely]

do we/should we have a survey for the instructors?
This way we can get a sense as to how many lessons are actually getting covered?
and anything else that seems relevant?

[DamienIrving]

I've taught the Shell, Python and Git lessons several times now with what I'd consider typical Software Carpentry audiences (i.e. a mix of complete beginners and more advanced people) and the timing consistenty comes out as follows (these estimates do not include coffee breaks):

• Shell: 3 hours
• Python: 6 hours
• Git: 1 hour

The biggest trap I've seen new instructors fall into is having the learners follow along command-by-command during the short periods of live coding. In other words, the instructor types a command (e.g. data = numpy.loadtxt('file.csv')) and then literally waits until the whole room has successfully entered that command before moving to the next command. When this is done, the times blow out dramatically. The 3 hr / 6 hr / 1 hr estimate above assumes that the instructor makes it clear to the audience that they are not expected to follow along during the live coding (i.e. if they do, the class won't be waiting for them). Instead, it should be explained to the learners that they will get a chace to try out what they've just seen during the regular challenges.

[DamienIrving]

As a consequence, a typical bootcamp schedule looks like this for me (for those who aren't part of the Commonwealth, morning and afternoon "tea" are coffee breaks):

Day 1

• 09:00 - 10:30: Unix Shell
• 10:30 - 11:00: Morning tea break
• 11:00 - 12:30: Unix Shell
• 12:30 - 01:30: Lunch
• 01:30 - 03:00: Programming (Python, R or Matlab)
• 03:00 - 03:30: Afternoon tea
• 03:30 - 05:00: Programming (Python, R or Matlab)

Day 2

• 09:00 - 10:30: Programming (Python, R or Matlab)
• 10:30 - 11:00: Morning tea break
• 11:00 - 12:30: Programming (Python, R or Matlab)
• 12:30 - 01:30: Lunch
• 01:30 - 03:00: Version control (git or svn)
• 03:00 - 03:30: Afternoon tea
• 03:30 - 05:00: Something extra (e.g. capstone example, SQL)

The only problem with this is that the SQL lessons don't fit in a 1.5 hour session. Everything else fits completely (i.e. we typically get all the shell lessons done, all the Python lessons done, all the git lessons done, and a capstone example usually fits in 1.5 hours if we choose to do that instead of SQL)

[rgaiacs]

@jdblischak Thanks to raise this issue.

However, I suspect this fast rate is not practical for many novice bootcamps
where the attendees have little to no prior experience programming. As a
recent example, @rbeagrie explains in a [blog post][rob] that they were only
able to teach 5 of the 6 Python lessons and had to completely skip SQL. I too
have had similar issues trying to cover too much in only two days and know
that many others have as well.

I also had similar issue at the workshop/bootcamp that end today. Only cover the
four topics of our Python lessons and most of the students said that the lesson
need to be a little slow.

do we/should we have a survey for the instructors?
This way we can get a sense as to how many lessons are actually getting covered?
and anything else that seems relevant?

@chendaniely Maybe @arlissc could help with that.

• Shell: 3 hours
• Python: 6 hours
• Git: 1 hour

@DamienIrving How do you accomplish the Git lesson in just one hour? My best
time is three hours and students said that was fast.

[gvwilson]

Shell: 3 hours
Python: 6 hours
Git: 1 hour

Are these times for the entire lesson (i.e., all the novice shell, all the novice Python, etc.)?

[DamienIrving]

@r-gaia-cs For the git lesson I don't get people to do the challenges - instead I get them to follow me command-by-command. I find that by the final afternoon (i.e. when I usually teach git) the live coding -> challenge -> live coding -> challenge cycle is getting a bit stale. For the collaboration lesson I get them to create their own GitHub account and a laptop/ and desktop/ directory on their own machine and we move between the both of them to create a conflict etc. Maybe I should write out how I run this lesson, as it's been a quite successful (and fast) way to do it... (and it requires only a very minor change to the lesson notes)

@gvwilson Yep, 3 hours total for all the novice shell lessons, 6 hours total for all the novice Python lessons and 1 hour for all the novice Git lessons.

[tracykteal]

@DamienIrving I'd definitely be interested in seeing how you run this lesson. I agree that a different model is nice at the end and this approach also sounds effective.

[gvwilson]

How in blazes do you teach all the novice Git material in one hour??

[DamienIrving]

@gvwilson @r-gaia-cs @tracykteal Oh, in addition to having the learners follow command by command rather than do the challenges, I also only teach the first 4 git lessons (introducing version control, a better kind of backup, collaborating and conflicts). I point the learners towards the open science and ssh keys stuff for future reference, but don't spend any time going over those materials. I know that's not ideal, but to fit everything into two days something had to give...

[rgaiacs]

Oh, in addition to having the learners follow command by command rather than
do the challenges, I also only teach the first 4 git lessons (introducing
version control, a better kind of backup, collaborating and conflicts).

@acviana did exactly it yesterday at needed ~4 hours.

[jdblischak]

@DamienIrving wrote:

The biggest trap I've seen new instructors fall into is having the learners follow along command-by-command during the short periods of live coding. In other words, the instructor types a command (e.g. data = numpy.loadtxt('file.csv')) and then literally waits until the whole room has successfully entered that command before moving to the next command. When this is done, the times blow out dramatically.

How common is this practice? In the past I have always given the students a pre-filled IPython Notebook and had them execute the cells along with me during the lesson. I have seen so much praise for live coding that I was planning on doing it for my upcoming bootcamp. But does live coding really mean not letting the learners follow along? What do they reference when they have to perform the exercises? The advice in novice/teaching/gerenal does not give me the impression that the students are not supposed to type along. An excerpt from that document:

• As you type at the command line, read out what you're typing. Remember that most learners can only go half as fast as you, because they have to watch you type then type it all in again themselves.

And from my anecdotal experience, students really want to follow along. Hence the advice to have a helper write the commands in the Etherpad during the lesson. Otherwise you get stopped every few minutes when someone falls behind and wants to see the last few commands again. Are students content to just watch when they are told to do so? I worry that will increase the likelihood that we lose them as they start checking their email inbox.

[DamienIrving]

@jdblischak This conversation is super relevant to @gvwilson's upcoming blog post about building better teachers. The time estimates I provided, of course, are highly dependent on how you actually go about teaching this stuff (as evidenced by estimates for the Git lessons ranging from 1 to 4 hours). Since you haven't seen me teach, my comments and time estimates are not nearly as useful as they could be.

Having said that, I start with a blank IPython notebook and do all the coding live. I tell people that they can sit there and try out commands as I talk, but it's not expected (or even desirable) that people will follow along line by line. I find that when people do follow along line by line, they can't sit back and actually take in what I'm teaching (e.g. their attention is grabbed by the minute details of entering the correct syntax for definiting a function, and they fail to listen while I'm speaking about the broader concepts around when to use a function and why they're useful).

When it comes time for a challenge, I point them all towards the relevant lesson notes on the Software Carpentry website. I say, "these notes contain everything I just showed you in case you need to refer back, and at the end of the relevant section in the notes there's some challenges I'd now like you to work on in pairs".

[erdavenport]

I really like the idea of having a guide to how long the material takes to run through for planning bootcamps, good call!

I recently taught the first 4/5 sections of git and it took ~ 3-3.5 hours (I'm so curious to see how you cover all of that material in an hour! We might need a show and tell). I probably go the opposite direction: I have them code along with me and have them set up their github accounts as part of the lesson. That likely slows things up quite a bit.

Maybe it would be useful to have multiple ranges: 1-1.5 hours "lecture style", 3-3.5 hours "live coding"? Or it's assumed 1-3 hours means 1 hour is on the "lecture style" end and 3 is on the "live coding" end?

[synapticarbors]

I just finished teaching the python sections at the University of Delaware bootcamp, using the v5 material. I had ~2 hours and 45 minutes allotted on each of the two days and I made it through lessons 1-5 (everything except 06-cmdline). I did selectively cut some of the material in the lessons I did cover and maybe did 1/3 to 1/2 of the challenges, but for the most part I systematically went through everything at a fairly slow pace, live-coding from a blank notebook.

[gvwilson]

@chendaniely can we assign this one to you?

[chendaniely]

@gvwilson yep!

Give me about a week or so to get all the survey's designed and some median number of hours posted.

I start a new job In DC tomorrow that starts with a 1:30am bus ride down... fun!

[jdblischak]

Since it is also relevant to this thread, I'll duplicate the time estimates from our recent bootcamp that I described in this post to the discuss list:

• Novice Shell lessons 1-7 (with 5-6 rushed): 3 hrs and 45 min
• Novice Git lessons 1-4: 2 hrs and 15 min
• Novice R lessons 1-4: 5 hrs and 15 minutes

[chendaniely]

@gvwilson Do you want me to send a PR to add median time estimates now? or after #759 ?

The estimates would either be on the actual .ipynb or .rmd file or in a separate readme per each topic

[gvwilson]

Please add now if you have 'em.

[chendaniely]

I just noticed @jdblischak's original comment asks to have time estimates for each individual lesson

@gvwilson How feasible is this? I personally would not be able to tell you how long shell lesson 2 vs shell lesson 3 took, but like the responses from everyone in this thread, an estimate for all of shell is much more feasible to recall.

[jdblischak]

@gvwilson How feasible is this? I personally would not be able to tell you how long shell lesson 2 vs shell lesson 3 took, but like the responses from everyone in this thread, an estimate for all of shell is much more feasible to recall.

But that only works if everyone teaches all the lessons. Just from this thread alone we can see that many people do not teach every single lesson in a section. And it is not easy to extrapolate. For example, the novice Python lesson on writing command-line programs has examples and exercises that are much more involved than the previous lessons. An instructor running out of time at a bootcamp that has to decide whether to continue with Python or move onto the next section needs to know that this lesson will take more time.

[chendaniely]

I agree that the individual lesson times are important. The original round of surveys did not ask for that level of detail :p

I'm making a reference to the post-survey issue: swcarpentry/DEPRECATED-site#618 so we can keep most of the survey specific discussions in one place.