Communicative Language Teaching Applied to Teaching Programming
By Geertjan-Oracle on Apr 18, 2009
The reason for these considerations is that we feel the student isn't getting as much out of the NetBeans Platform trainings as they could be, they're not interacting with the materials themselves, and they're not full participants in the course. That's partly because the course is only 2 days in length and there's a lot to cover, even though we're not trying to cover absolutely everything, just the core concepts, even 'just the core concepts' is really a lot of material to cover in 2 days. So, rather than scrapping the 2 day course and doing 3 day courses, which wouldn't completely solve the problem anyway, we're basically talking about using communicative language teaching methodologies in the programming classroom. The extent to which that is realistic remains to be seen, but is probably fairly radical, given the programming courses I've attended thus far.
Some practical examples:
- Don't Try to Cover Everything. The point is not to teach everything. Apart from that being impossible in two days, it also forces too much speaking time by the instructor and too little engagement from the student. And how much of a 1 hour presentation will be remembered anyway if all that happens is the teacher speaking?
- Minimize Lengthy Talking. In a one hour session on some topic, the instructor should never talk more than 20 minutes. The rest of the time, the students should be doing things, discussing things, debating things, programming things. Even though less material will be covered in this way, the material that IS covered will be remembered much better than is currently the case.
- Homework. In a 2 day course, the 1st day should always end with some very specific homework. But the homework should be fun. For example, give each student a piece of paper containing three words (e.g., "Node, FileObject, TopComponent") and then tell them they have to say something about each of those 3 words at the beginning of the next day (instead of the teacher doing a 'revision' of the previous day by simply stating what had been covered in the previous day, i.e., again without any interaction with the student). Other homework could be to summarize a presentation from the day into 100 words or to pick a theme from the day and briefly summarize it in a few minutes revision for the next day.
- Debates. When introducing the concept of 'modularity', talk about it for a bit, and then get the students to discuss in small groups what they think the most important advantages and disadvantages might be. And get them to rank these and then let them compare their rankings with another group and then eventually report back to the whole group. Or split the class into two groups and tell one of them to defend modularity while the other attacks it. And give them 5 minutes to prepare, which means they'll need to discuss it together first. (Maybe do that on the second day as a kind of revision.)
- Games. Tell one person: "You're a Node", tell another one "You're an ExplorerManager", another one "You're a TopComponent", another one "You're a BeanTreeView", and the final one: "You're an IconView". Then tell them to discuss together how they could simulate/explain how they relate to each other, after which they present their story to the whole class. (So, the whole group stands in front of the class and the TopComponent says: "I am a window in a NetBeans Platform application, holding Swing containers, such as explorer views, such as a BeanTreeView. I need to implement an ExplorerManager in order for a Node to be displayed in an explorer view." and the BeanTreeView says: "I am the container within the TopComponent where the Node is displayed" and the ExplorerManager says: "But I am the one that actually causes the Node to be displayed" and the Node says: "I am a visual representation of a business object but I need an explorer view, such as a BeanTreeView, to display myself to the user", etc.) I imagine it's very unlikely you'll ever forget what a Node is, for example, if during the course the instructor says to you: "In the next exercise, you are a Node." However, the instructors need to do a similar simulation first (e.g., WindowManager and TopComponent), in order to show what you want the students to do, otherwise the exercise could be very confusing. Another game could be to tell them to look at NetBeans IDE and explain which of the APIs are used where (i.e., near the end of the 2nd day, at which point most APIs have been covered in one way or another). This could be a good exercise for the "Other Miscellaneous APIs" session, after lunch on day 2.
- Sustained Code Example. Use the Anagram game throughout the course, as the "authentic text" of the communicative approach, where the application would be ported to the NetBeans Platform, one step further in each following session, ending with a nice, modular, realistic application at the end of day 2. Start with a very brief intro to modularity, then do the window system as the first full topic. There, migrate the Anagram game step by step to the NetBeans Platform, but only into a TopComponent, then later, when Lookup is handled, split the code further, creating a service and a service provider. In each case, do the example step by step with the students following, i.e., doing the same. Then get them to work on their own to get a few very small steps further, i.e., without guidance from the instructor. This way, Nodes and FileSystem can also be covered, even the Visual Library could be used with the Anagram Game, after the FileObjects are put into the Palette as Nodes, from which they can be dragged and then dropped as Visual Library widgets.
- Swing on the first day, Modularity on the second. Spend the first day on the Swing extensions, such as the window system and the Visual Library. Then only deep dive into Lookup and 'what is a module' on the second day. I.e., leave the technical architecture discussions to the point where the students have already seen the many Swing goodies that the NetBeans Platform provides, i.e., all the UI pieces, which is a lighter topic, instead of getting bogged down by ProxyLookups in the second hour of the course, which is currently the case.
- Discovery. Don't say: "The window system has the following features" and then list them and explain them. Instead, mention one or two of them and then tell them to find all the others. (But give them a specific number to find, say 5, and then compare with someone else to learn about more of them, i.e., not from the instructor, but from other students.) Also make sure that it is clear what a window system feature is before the task begins, otherwise you'll get responses that are not really relevant.
- Variety. A big aspect of all of this is variety. Not just to keep the students awake, but also because different students learn in different ways. (And none do so by sitting like a zombie watching a teacher's moving lips.) Some are very visual, some will understand things in a better way if done in a different way. Some need a lot of activity. By constantly varying the ways things are done, chances are that a broader group of students are being catered to than before. Plus, chances are that students will be more likely to want to give these trainings themselves, which is one of the main reasons we're giving them, i.e., in the hope that others will do them instead of us (since we're not trainers ourselves and because we can't be everywhere in the world at the same time). If we're having fun in the course and playing lots of games (rather than talking for hours, which is a bit intimidating to be expected to do yourself and why would you want to anyway), who wouldn't want to facilitate similar learning experiences to others?
- One-to-One Focus. The above approaches enable the instructor to walk around to verify that students are correctly understanding the material. Rather than asking questions from the front, to which only the one or two very confident students will respond, this enables each of the students to receive much better attention, since even the shyest student and the student that has the most difficulty with the material can then be approached and assisted. And they're much more likely to ask questions when the instructor is talking to a small group of 2 or 3 than when doing so from the front of the whole group. Another point here is that you're likely to be solving problems of understanding while walking around the room and talking to the groups, so that when they give feedback at the end of the session, i.e., when they report on their findings, none of them will be wrong because you've made sure that their answers will be correct before you even get to that stage of the session.
I think the above conversion of the Communicative Language Teaching approach would leave the student with a much better grasp of the NetBeans Platform, since they've been grappling with the concepts & code themselves throughout the two days, rather than sitting passively listening to the instructor and passively copying/pasting code from tutorials during the workshops.