One of the great outcomes of studying instructional design from a theoretical perspective is the ability to spot patterns in teaching.
When teaching software and coding, one typically encounters two theories in use.
Behaviorism : Just teach people the behavior and reward them for doing it correctly. Based on B.F. Skinner and others.
Best use is for the fundamentals of the subject. In math, it’s basic arithmetic. In languages, it’s alphabet, spelling, and grammar. In music, it’s notes, rhythms, and scales. If the teacher says “you just have to memorize this,” that’s behaviorism.
If you’re evaluating performance, it’s often done through multiple choice, true/false, and other means of regurgitating facts. Students are rewarded for memorizing, not applying.
If you were making a recipe, you would be rewarded for following all of the instructions correctly, rather than how good the recipe tastes. Behaviorism does not work in all kinds of learning.
Constructivism : “Learn by doing.” Base your learning on previous experience in the world, and apply that previous learning to the problem at hand.
If you’re following a recipe, you’re the person who changes the ingredients the first time you try it. You know what you like and what works from previous cooking experiences. You know you don’t like mushrooms, and you’ll leave them out of this recipe. You substitute butter for margarine, chicken broth for beef broth, and add meat to vegetarian dishes.
Best use is “doing” subjects once the fundamentals are mastered. Once a music student has learned a piece of music by a Baroque-era composer, how would the student apply those techniques and styles to the next Baroque-era piece she learns?
Evaluation happens through some kind of final product, not through the work along the way. Typically this is a project-based evaluation: a final research paper, a piece of working software, a film, a performance.
Constructivism shouldn’t be applied where there are absolutely right and wrong answers. It’s more about the shades of grey than the extremes of the spectrum.
In the software and coding world, behaviorism drives most instruction one encounters. It’s the “help files” associated with the software: go here, click this, type that, and you’re done. In code, it’s dominated by StackOverflow and developer blogs: here’s a chunk of code that does this thing.
Often, a coding class will start with examination of that chunk of code and some of its nuances. In that moment, students would tell you that they understood that code and its use.
The next thing students are instructed to do is constructivist. “OK, now apply this to your own project.” No further guidance is given in that moment.
This critical moment is the time when students decide they are not “good” at programming or technology. Instead, these students are a victim of poor teaching.
The instruction isn’t necessarily bad. The instructor explained that code in minute detail. The idea of applying that code to your own project isn’t bad either. Unfortunately, there’s a step missing in between.
That step is transference. This is the moment you take a concept you learned in one context and apply it to the next problem. It’s really, really hard to do.
Most people experienced this in grade school in math class. You memorized basic arithmetic all day long. You knew those times tables! But then… there were word problems. Word problems required you to read a few sentences, identify the problem that needed to be solved, identify the math to solve it, and calculate the answer. Most students did fine with basic arithmetic and failed miserably with word problems.
Professional software engineers are very good at transference. Instructors are really good at it too. However, the majority of students need help in making the leap from one context to the other.
There are techniques that assist with transference. Starting with a detailed explanation and ending with “try it yourself” are not fundamentally bad ideas. However, there’s much more in-between that needs to happen for an effective outcome for most learners.