In order to do a better job putting together my thoughts and knowledge on the subject, I precommitted myself to giving a presentation on learning. My specific goal for the presentation is to inform audience members about how humans actually learn and teach them how to leverage this knowledge to efficiently learn and maintain factual and procedural knowledge and create desired habits.
I will be focusing a little on background neuroscience, borrowing especially from A Crash Course in the Neuroscience of Human Motivation. I will heavily discuss spaced repetition, and I will also talk about the relevance of System 1 and System 2 thinking. I will not be talking about research, or about how to discover what to learn; for the purposes of my presentation, people already know what they want or need to learn, and have a fairly accurate picture of what that knowledge or those behaviors look like.
Given that I will only have an hour to speak, I will be unable to explore everything I might like to in depth. Less Wrong (both the site and the community) are my most valuable resource here, so I am asking two things:
- In one hour, what would you cover if you earnestly wanted to improve people's ability to learn?
- What background material do I need to ensure fluency with? This should be material that I need to have adequate familiarity with or else risk presenting an error, even if I don't need to present the material itself in any depth.
The audience will be students and faculty in a Computer Science department. In decreasing order of number of members, the audience will be Masters students, seniors, Ph.D candidates, professors; no Junior or lower-level undergraduates, so I will probably use computing analogies that wouldn't make sense in other contexts. Because of the audience, I'm also comfortable giving a fairly information-dense presentation, but since I intend to persuade as well as inform the presentation will not be a report.
I've taught C, Java and Python at a university and (a little) at the high school level. I have noticed two simple things that people either surmount or get stuck on. The first seems to be even a basic ability to keep a formal system in mind; see the famous Dehnadi and Bornat paper. The second, I have heard less about: in programming, it's the idea of scope.
The idea of scope in almost all modern programming languages goes like this: * A scope starts at some time (some place in the code), and ends somewhere later. * A scope can start before another ends; if so, it has to end before the "outer" scope. * Inside a scope, objects can be created and manipulated; generally even if another scope has started. * Unless something special is done, objects no longer exist after a scope ends. * Pivotally (this seems to be the hardest part), a objects can be created with one name in an outer scope and be referred to by a different name in an inner scope. Inner scopes can likewise create and manipulate objects with the same names as objects in an outer scope without affecting the objects in that outer scope.
It's really hard for me to think of an analogous skill in the real world to keeping track of N levels of renaming (which may be why it gives students such difficulty?). The closest I can think of is function composition; if you don't have to pick your way through symbolically integrating a composed function where the variables names don't match, I have pretty high confidence that you can manage nested scopes.
EDIT: There are two other, well-known problems. Recursion and pointers. I've heard stories about students who were okay for a year or two of programming courses, but never "got" recursion or, never understood pointers, and had to change majors. I've seen students have enormous difficulty with both; in fact, I've passed students who never figured one or the other out, but managed to grind through my course anyway. I don't know whether they dropped out or figured it out as their classes got harder---or just kept faking it (I had team members through grad school that couldn't handle more than basic recursion). I'm not inclined to classify either as "programming gear" that they didn't have, but I don't have data to back that up.