I think some of the lessons here are useful to the situation of someone who already has learned some programming concepts (grammatical structure), but is struggling with a new programming language, especially one that is based in a different paradigm. Or someone who has a handle on procedural programming for instance (the basic mechanics of doing something with the language), but now is being introduced to compositional/design issues.
In other words: someone who can get by in the language, but is not fluent, and may need help in any number of areas, depending on their background.
The course notes I'm looking at are for a graduate-level course in designing a "needs-based curriculum" for teaching ESL students. The aim of the course was:
To teach you how to
listen to your students
analyze their speech
distinguish their strengths and weaknesses
apply needs-based curriculum principles to design sequences of activities that aim to address their weaknesses and difficulties
The "needs-based" philosophy is defined as
- Learning is not a process of information transfer
- We learn best by doing, through reflection, interaction, and hands-on practice
- We also learn best when instruction is suited to our needs
In this framework, the challenge for the teacher/tutor then is to combine
-
a curriculum designed around the students' needs/interests ("content objectives"), something they will be intrinsically motivated to use language for, with
-
an analysis of the particular technical weaknesses of the students' pronounciation/grammar ("language objectives")
your goal is to merge your content and language objectives:
- define your content goals;
- define your pronunciation goals > review target vocabulary and try to anticipate the difficulties your students might experience and to address them in a systematic manner
I think this is a really useful framework for teaching programming as well, whether the teaching environment is structured around fixed lessons or more open-ended assignments. On the one hand you are attentive to the learner's technical weaknesses; on the other, you want to help the learner find motivation to work on them. Otherwise, without motivation the point may seem academic to the learner ('why do I need to do it this way when I've always done it that way just fine?'); but without pinpointing the technical issues, it's not instructive at all.
The following is the suggested sequence of a lesson/tutoring session.
- introduce topic/content of the lesson
- introduce pronunciation goals (explicitly or implicitly)
- design controlled exercises: listening > production
- design communicative exercises > proceduralization
Note that the listening/analyzing phase happens not just in an initial evaluation, but in each session. Also, I see some similarities here with the IES recommendation to "interleave example solutions with problem-solving exercises".
Of course, with natural languages the dimensions of learner proficiency are much more studied and well-defined than in programming languages. There are standardized tests that help determine a speaker's proficiency and weak areas, for instance, and books written about specific pronounciation problems say a Polish speaker will likely have in spoken English.
By comparison, styles of programming are less established as best practices. What in one context is appropriate to use might in another context be completely wrong (overengineered, for example). Unlike in natural-language pronounciation or grammar where a native speaker can nearly always tell you immediately that the usage is wrong in that context, in programming two 'native speakers' often disagree on a particular usage. In part this is because the 'context' is much wider - it expands beyond phonetic/grammatical context and into 'what the code is being used for', how it's being developed, etc. (In this sense it may be more worth comparing teaching programming style to written composition).
But it still may be worth considering whether there are generally useful approaches/exercises/points to make when teaching, say, someone learning a dynamically-typed language coming from a static-typed language; or a functional language coming from an object-oriented one.
-
Avery & Ehrlich, Teaching American English Pronunciation (Oxford Handbooks for Language Teachers Series) (1992)
-
Celce-Murcia & Larsen-Freeman, The Grammar Book: An ESL/EFL Teacher's Course, Second Edition (1999)
-
Swan & Smith, Learner English: a teacher's guide to interference and other problems, Volume 1 (2001)
-
Read/skim some of the scholarly articles for this class
-
Look for articles on the teaching of written composition that might be useful
-
Look for articles specifically comparing language-learning to learning programming