A course as experiences

Experiences are things students do, like reading, running simulations, and writing programs. All learning is through experiences, or inferred from experiences.

A course offers a base set of experiences. Students choose whether to participate in each experience. Students can add their own experiences, if they choose.

A planned experience is effective if, after engaging in it, students have the knowledge the experience designer set as the goal of the experience. Effectiveness depends on many factors, including:

• Whether students have the prereq knowledge needed to benefit from the experience.
• Whether the experience overloads students' cognitive capacity.
• Whether there are inferential gaps in the experience. For example, the designer might leave out steps that are obvious to an expert, but not to students.
• Whether students exert effort. This depends on how relevant the experience seems to students, whether they have the time to spend, and other factors.

A course designer should lay out an experience plan that leads from students' assumed initial knowledge state, to a goal knowledge state, while taking prereq knowledge into account. For instance, students should know what variables and If statements are before they tackle the input filtering pattern. The plan's graph need not have a single path, but often that's what is done for convenience.

Knowledge sequence in this course

The goal is to use patterns to complete tasks. Patterns are expressed in terms of computer mechanics. For example, data filtering:

dataItem = [read data from source]
If [dataItem meets criteria] Then
  [Store dataItem for processing]
End If

Understanding this pattern requires students to understand variables and conditions. These are the mechanics of the programming language.

To understand language mechanics, students needs a mental model of the computer that is running a program. Rather, they need a mental model of a notional computer, that includes the components they need to know about in order to write Excel VBA programs. Usually students are left to build a mental model themselves.

So the overall course knowledge sequence is:

• How computers work
• Language mechanics
• Patterns

An animated Excel VBA simulator has been written. It's in JavaScript, and runs directly in the browser. On the fly, students can change data in the spreadsheet, variable memory, and the instruction pointer. This permits exercises with the mental processing variety that encourages deeper understanding. For example:

• What will the variable total be at line 15?
• What would happen if cell B2 had a name in it, instead of a number?
• What input can the user give to crash the program?

Active learning and cognitive effort

Students must exert effort to learn. Effort is necessary but not sufficient. Productive struggle, not just struggle, is the goal of course experiences.

Suppose we want students to learn the input filtering pattern. What experiences could they engage in?

1. Read a description
2. Watch a fixed simulation
3. Students manipulate a simulation as they run it
4. Watch someone else implement the pattern
5. Be given a task where they are told that the pattern is required, and needs little adaptation. Minimal transfer.
6. Be given a task that does not explicitly require the pattern, but for which the pattern is appropriate. Students have to recognize that the pattern is appropriate, and perhaps adapt it. Problem solving, and moderate transfer.

Time and effort required increases as we go down the list, except that earlier steps reduce the effort required for later steps. For example, doing item three is easier when students have done one and two, compared to jumping in at three to start. Mathematically, cognitive effort needed to succeed can be modeled as:

\[e_{p}\approx\sum_{i=q+1}^{p}\Delta p\]

p is the index of the experience in the list, from 1 to 6. q is the index of the highest experience students have already had. Delta p is the cognitive load that experience p adds above experience (p – 1).

There's a limit to the simultaneous cognitive effort a human can exert. If students' first experience is, say, 5, the cognitive load will be the sum of the deltas of experiences 1 to 5, and will exceed students' processing abilities.

However, if students experience 1, then 3, and then 5, the cognitive load of each step may be below their processing abilities. This will take more time, but is more likely to be effective.

The course designer should:

• Enable students to achieve course goals
• Within course time constraints
• By sequencing experiences
• That involve productive struggle
• Within cognitive load constraints.

Transfer

Transfer is the hippo in the closet. Experience 6 above is necessary for transfer. Delta 6 will also be higher than delta 5, probably significantly higher. Therefore, helping students learn to transfer will take significantly longer than stopping at minimal transfer. This means that fewer topics would be covered, given that time for the course is limited.

What to do? Consider two outcomes:

• Alpha: students know a few topics, and can use them in a variety of tasks.
• Beta: students know more topics, but only can complete tasks that are almost identical to tasks they have done before.

Which would be better for students in the long term? It's hard to say, because this course is the first in a sequence of four. Beta might work well if subsequent courses helped students learn to transfer. This course would supply a base of patterns that could be elaborated in other courses. However, if subsequent courses did not emphasize transfer, then the current course might be the only chance students have to learn problem solving in a programming context.

Course coordination is minimal in our institution. Courses are designed more or less independently. Alpha seems the safer course (no pun intended).

Formative feedback

Students will receive formative feedback for their programming exercises.

Beliefs

A growth mindset should be encouraged from the beginning. It should be reinforced throughout the course.

Students should expect that their programs won't work the first time. They should know that debugging is part of programming, not something that people do when they're not good at programming.

Students should expect to spend time on the course every week. Regular learning exercises should help.

Pseudents can help with this stuff.

Debugging

At least two things here.

First, students should make testing and debugging part of the way they create programs. Test early, test often.

Second, students need to be comfortable with the mechanics of debugging. A debugging game has been created for that purpose.

Variance in student performance

The range is wide, easily five-to-one. This course is calibrated for the average student. Poor students will need to spend more time on the course than most students, perhaps 150 hours rather than 100.

What about good students, who complete course requirements in less time? Some will devote the extra to other pursuits. Those who enjoy programming might want more to do.