I'd actually disagree and my current research in CS Education is attempting to incorporate sport pedagogy into the learning process! I do plan to read through your link more thoroughly later tonight so thanks for that.
In a nutshell, we knock that CS1 courses have a high number of drop/fail/withdrawals due to several different factors. These include course difficulty, time management skills, and not feeling welcomed in the community (lack of representation, assuming CS students must love video games, etc). I don't focus much in inclusivity (though a number of faculty at NC State do), but I'm looking for methods to reduce difficulty. My thesis stems from methodologies I've used while teaching martial arts - specifically focusing on lower-level "build blocks" practice.
We can represent different learning activities by the amount of "creation" a student must engage in - Passive (watching lectures) require no creation, Active is repeating solution steps, Construction is critiquing steps, and Interactive is a co-creation process between the student and another student, instructor, or system. These form the ICAP framework by Mickie Chi. My arguments are that if a student is struggling with an Interactive exercise, like a traditional coding problem, then they should "downgrade" their practice to something lower level like self-explanation or debugging. However, if THOSE activities are still difficult, we can downgrade to an even lower-level of having them simply repeat (the mindless 'copy the dictionary' activities modern education hates).
My rationale again looks at how technical skills, like martial arts, are learned. Typically we start with warm ups, a brief demonstration on a few movements from the instructor, and then students are asked to pair up and drill the moves. Then the instructor builds on the moves with another demonstration, and then students repeat their process. Eventually, students spar (or apply the technique in a live problem). I argue that traditional coding problems are analogous to live sparring because students need to incorporate writing code, problem solving, debugging, code tracing, etc. If they struggle with some of those skills, they struggle in the activity. Rather than having them learn all the skills "in situ" while coding, maybe lower level deliberate practice targeting a single skill can help strengthen their overall foundation.
> specifically focusing on lower-level "build blocks" practice
This has been my experience with teaching math and CS.
The biggest causes of failure is not identifying and teaching prerequisite skills.
The key point is prerequisite. Many times the skills needed to pass a math or CS class are not part of that class's curriculum.
Students who have encountered the building blocks already tend to do well, students who have not, tend to fail - no matter how much the class goes over the material in this class - because the problem lies before that material.
That's where I think specifically the Active exercises can help. We gave students in a CS2 optional typing practice throughout the semester [1]. These students performed better on exams, made higher learning gains and uploaded less buggy code to GitHub for projects. The results were also significant for students that performed below the median on the first midterm and only started doing the exercises AFTER the midterm. Granted, the students were still self-selecting to improve their status, but it does help establish methods for helping even students in higher level courses.
This is my experience as an adult studying calculus, linear algebra, dynamic programming etc.
Calculus is mostly algebra. If you can’t reliably solve algebraic equations, derivatives and integrals will probably be a step too far.
Algebra is mostly arithmetic. If you can’t reliably add and multiply rational numbers, solving for unknowns is going to be patchy at best.
The key part as a student is learning to recognise when I needed to re-tread the primitive operations. Having to go back and practice the mental arithmetic I first learned in primary school was a hit to the ego, but at least I could recognise and take that step. When I was in my late teens / early 20s I was much less able to swallow my pride and back-track.
> When I was in my late teens / early 20s I was much less able to swallow my pride and back-track.
This is, in my opinion, one of the issues with adults attempting to pick up new skills, in addition to that mythical "free time". Many of us have been conditioned that if we aren't masters in something immediately, its a lost cause. If someone suggests that we do "what kids do", then we think we're too "grown up for that". A good example would be tracing drawings. Many kids learn this way, but to suggest an adult do it and provide positive reinforcement in doing it is almost non-existent at the adult level.
Honestly, an adult version of Sesame Street (not "adult" in sex, drugs, violence, but the simplistic dialogue with repetition) may help adults learn a new language, but its competing with other factors like time, general attention, thinking this is "worthy" of our time, etc.
That doesn't make sense. There always is some overlap between tasks somewhere, but learning to program is generalization, and learning martial arts is motor control. There's no reason for them to be connected. That words like "active" can be applied to both, doesn't mean much. Should you find that your method works better than an existing method, that doesn't mean the metaphor for your method has any basis in reality.
> learning to program is generalization, and learning martial arts is motor control
I disagree; both programming and martial arts require a level of technical motor control. Its easier to define and connect in a physical skill since that is where motor control is studied. However, programming as a technical skill involves familiarity with syntax, familiarity with the tools (literally keyboard and mouse), and translating plans into valid syntax. Likewise, sparring in martial art is as much a problem solving skill as it is in programming - you need to evaluate the problem at hand and do problem decomposition to create subgoals until you produce an actionable item.
> There's no reason for them to be connected
The connection to martial arts works for me because that's something I've done for over a decade. It doesn't immediate click with everyone if they don't have that same history with it. However, many people have seen parallels when I describe this through learning music, dance, chess, or second language acquisition. They recognize the skill was a combination of lower level technical knowledge and higher level problem-solving/creativity. My base thesis is "if you're struggling, why not focus on refining the lower level skill you seem to be having trouble with"?
In a nutshell, we knock that CS1 courses have a high number of drop/fail/withdrawals due to several different factors. These include course difficulty, time management skills, and not feeling welcomed in the community (lack of representation, assuming CS students must love video games, etc). I don't focus much in inclusivity (though a number of faculty at NC State do), but I'm looking for methods to reduce difficulty. My thesis stems from methodologies I've used while teaching martial arts - specifically focusing on lower-level "build blocks" practice.
We can represent different learning activities by the amount of "creation" a student must engage in - Passive (watching lectures) require no creation, Active is repeating solution steps, Construction is critiquing steps, and Interactive is a co-creation process between the student and another student, instructor, or system. These form the ICAP framework by Mickie Chi. My arguments are that if a student is struggling with an Interactive exercise, like a traditional coding problem, then they should "downgrade" their practice to something lower level like self-explanation or debugging. However, if THOSE activities are still difficult, we can downgrade to an even lower-level of having them simply repeat (the mindless 'copy the dictionary' activities modern education hates).
My rationale again looks at how technical skills, like martial arts, are learned. Typically we start with warm ups, a brief demonstration on a few movements from the instructor, and then students are asked to pair up and drill the moves. Then the instructor builds on the moves with another demonstration, and then students repeat their process. Eventually, students spar (or apply the technique in a live problem). I argue that traditional coding problems are analogous to live sparring because students need to incorporate writing code, problem solving, debugging, code tracing, etc. If they struggle with some of those skills, they struggle in the activity. Rather than having them learn all the skills "in situ" while coding, maybe lower level deliberate practice targeting a single skill can help strengthen their overall foundation.