Working with Mark Guzdial and Richard Catrambone, Lauren Margulieux has recently had a couple of papers about using subgoals in teaching accepted for publication:
“Subgoals Improve Performance in Computer Programming Construction Tasks”
“Subgoal-Labeled Instructional Material Improves Performance and Transfer in Mobile Application Development”
The details of the papers are discussed by Mark on his blog, but basically, Lauren took Richard Catrambone’s subgoal model of learning, applied it to 40 Georgia Tech computer science students, and then monitored how well they learned the material compared to students who were not given subgoals. Catrambone’s work is focused on how the use of subgoals can help students develop better mental models in programming. Interestingly, although perhaps not surprisingly, Lauren found that the subgoal model of learning statistically increased students’ ability to transfer their knowledge. Students taught via subgoals retained the material longer than their counterparts. When asked to think aloud to share their programming process, students taught via subgoals continued to solve new problems in terms of their own developed subgoals.
This work is exactly what we want to see in education research: Lauren tried something and it worked brilliantly. So, why isn’t the idea implemented at Georgia Tech? Good question.
I have stumbled upon this teaching concept in my own practice as a TA for CSE 231 at MSU. I teach a lab section once a week where students are presented with a problem that they must write a program to solve. The lab description generally walks them through several parts of increasing complexity, and each part explains what a student should be doing to create a solution. But, often, students are unable to make the connection between the problem space and its computing representation. My lab sessions have started going much more smoothly since I began posting pseudocode subgoals. Here’s how class runs now:
- Students come in and find their partner. I give them the first 20-25 minutes to start brainstorming solutions on their own.
- After that time has passed, I bring the class back together to create a series of subgoals for solving the first part of the lab. The subgoals are generally suggested by the students, with direction from me when necessary.
- Students are given another 20-25 minutes to implement the subgoals. Then we reconvene to identify the subgoals for the next part of the project.
Since I started running class this way, I have found that students are less frustrated with the programming process. They don’t complain about having “no idea” what is happening. They have incremental steps to take toward a greater goal.
I find it really interesting that I discovered this teaching technique on my own through trial-and-error in the classroom, and that it is actually an idea whose use is worthy of publishing in SIGCSE conference papers.
Lastly, I want to note that I find the subgoal teaching technique to be very similar in practice to the idea of problem-based learning – except we are instead motivating students with bite-sized tasks that help them keep track of the direction they will be headed while solving the larger problem.