[OSCTC-planning] Curriculum questions

[Naomi Ceder]

In response to some off the record carping on my part Asheesh asked me to
put my keyboard where my mouth is and offer some thoughts on curriculum
planning.

First of all let me emphasize that you all are doing great work and deserve
great support and appreciation from the Python community.

*Disclosure: Biases*

To give an idea of where I come from I taught high school (and some middle
school) in a private school for 25 years. In that time I taught Latin,
Greek, and the after a career change, Pascal, C, C++, Python and Java. I
taught Python to 8th graders on up to 12th graders for 11 years. I also
have worked on two books, Head First Programming (I parted ways with
O'Reilly over pedagogical reasons after completing a first draft) and the
Quick Python Book, 2nd ed.

So to reveal my biases, my main concern with curriculum and pedagogy in
community based programs is that it seems to be to be very traditional and
(for want of a better word) linear. In the Chicago Python workshops I
taught at we used pretty much the Boston workshops curriculum. The pattern
was familiar - a morning of linear lecture on the Python, followed by the
afternoon of project work. The thing is, I always found that was not a
great way to teach. Rather than argue this myself I'll just reference Kathy
Sierra's great post about "Just in case" vs. "Just in time" Learning -
http://headrush.typepad.com/creating_passionate_users/2005/03/motivated_to_le.html

Following on that, I'm a fan of constructivist learning, where the learner
does experiments and figures out how a system works - research is pretty
clear that learning derived that way is much more effective than lecture.

The other thing I learned while working with the Head First series was to
beware of "cliffs"... that is, where you lead the learner down a path until
suddenly you get to a point where they have know idea what's going on...
and feel like they're being pushed off a cliff.

So those are my biases.

*Git Curriculum comments*

Those biases drive my comments below on the git unit at
https://openhatch.org/wiki/Open_Source_Comes_to_Campus/Curriculum/Git

Student section

   1. I suppose this is covered by the instructor (although instructors can
   be variable) but as a newcomer, I probably don't really understand why git
   matters... even a few words on why I would want to worry about version
   control and how it can help a distributed project would be useful, I think.
   2. What does "fork" mean? And why do I want to do that? Or will I have
   already had that explained to me?
   3. Again, what does "clone" mean/do?
   4. Find a Task and Resolve a Task would be much better with example
   screen shots... what is said is accurate, but someone is doing this for the
   first time everyone one of those things is going to be an unknown, a center
   of uncertainty... I'd try to make it clear what they can expect.
   5. Same thing for commit and push... some sample out put would be very
   good... otherwise how do I know if I've done it right? what if I enter
   something in correctly, what do the errors look like?
   6. Again, what is a "pull"? Why do I want to do that? What  happens when
   it is or is not approved?
   7. Setting mulitple remotes - again, some sample output to make sure I'm
   doing it right would be helpful, but the big issue is making it clear why I
   would want to do that, preferably with a couple of brief scenarios that I
   could understand. My guess is that people who've never worked on a project
   with git before are going to be fairly clueless as why they are even
   learning this.
   8. The resolving merge conflicts section does a much better job - there
   is an easy to follow scenario, there are sample results, the reason that I
   should learn is much clearer.

Teacher Section

This is fine for someone who both is familiar with git and has teaching
experience. However, inexperienced/unconfident teachers aren't given very
much to go on.

I also have a quibble with the approach. Encouraging questions through IRC
does have the advantage that more students can see the question and the
answer (or the instructor can pick questions to discuss orally). But it
also adds another obstacle. If I'm struggling with the exercise and not
familiar with IRC, I now have TWO problems to resolve before I'm going to
get anywhere. And if IRC is the preferred way of asking questions and I
don't feel comfortable with that, I'm going to feel extra stupid for having
to raise my hand and ask the dumb way.

For this reason I really encourage that some good instructors are
"floaters", circulating amongst the students, checking screens for errors,
smiling and making eye contact, even asking if there are any questions,
rather than letting students just stew in their own juices.

The final note I want to raise is evaluation. What ways do you have of
evaluating how well the material and the teaching is working? I'm not
suggesting a standardized test at the end, by any means, but are there any
less formal measures recorded? Like how far each student gets? How
successful they are? How many problems did the have and where? I used to
make notes on my materials as I taught recording questions asked that I
didn't expect, making notes on where most people struggled, etc. Just
something to think about.

*Final notes:*

Of course a skilled teacher with a small class would be fine with this as
it is... but if you are using amateur instructors, the student/teacher
ration is more that 6 to 1, etc. then my experience would be to look for
trouble.

Please take all of this with a large grain of salt - I only teach a few
times a year now, and I was a bit of a quite rebel when I was teaching. I
also know that engaged and enthusiastic teachers and students can do
amazing things, even when not everything is perfectly aligned.

And finally, since at this point in my life I don't have much time to
contribute to actually work on these issues, I'm offering these suggestions
very much with a sense of appreciation for the work you're doing, and a
desire to help in the small way that I can.

Cheers,
Naomi Ceder


-- 
Naomi Ceder
https://plus.google.com/u/0/111396744045017339164/about
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhatch.org/pipermail/osctc-planning/attachments/20140216/78017bfe/attachment.html>