Two major camps in education are Direct Instruction (DI) and Inquiry-Based Learning (IBL). The former prioritizes standardization, structure, and detailed lesson guides; the latter prioritizes discovery and exploration. I think it’s intuitively clear that neither approach is always better in every situation; the optimal blend surely depends on the student, teacher, and context.
But recently, DI has gained some momentum, so in this post, we’ll look at two examples and consider potential implications for computer science.
1. Reading
In the world of reading education, the phonics approach corresponds to Direct Instruction; it explicitly teaches the connection between letters and sounds. On the other hand, the whole language approach is more like Inquiry-Based Learning; it prioritizes the discovery of words in the context of sentences, pictures, and books.1
My impression is that phonics has basically won. It produced the “Mississippi miracle” — in fourth-grade reading, the state was ranked the second-worst state in 2013 and 21st in 2022 — and other states have passed similar legislation.
Unfortunately, phonics isn’t exactly thrilling. Instead of discovering words by reading fun short stories, students need to memorize a bunch of rules like the “silent e rule” and “when the letter c is followed by the vowels e, i, or y, it usually makes its soft sound.” And for teachers, teaching phonics can feel too strict and regimented; some call it “drill and kill.” The whole-language approach seems more fun and student-oriented since it ostensibly adapts to their capabilities and needs. But when there’s lots of evidence that something works, even if it looks boring, it’s probably worth considering.
2. Math
Earlier this month, the Associated Press covered the proliferation of phonics and asked, “What about math?” Is there something like phonics for math? Here’s what they said: “In some ways, the best practices for math parallel the science of reading, which emphasizes detailed, explicit instruction in phonics, instead of letting kids guess how to read a word based on pictures or context clues.”
The article links to a practice guide that makes six recommendations for math education based on “high-quality evidence-based research studies.” (I find it amusing that immediately after describing three levels of evidence, the authors of the guide claim that all of their recommendations meet the strongest level.)
Although the guide focuses on small-group interventions in grades K-6, I think a few of its recommendations are particularly intriguing and potentially applicable to more general settings:
Systematic Instruction: Learning materials should incrementally help build students’ knowledge toward specific learning outcomes. Teachers should review relevant previously taught material before introducing new content, lessons should focus on relatively smaller tasks, and students should receive immediate feedback when they have a misunderstanding.
Mathematical Language: Since math is (unsurprisingly) full of mathematical language, it’s critical for students to develop fluency from the beginning. For example, instead of referring to “a+b = b+a” as the “flip-flop property,” teachers should refer to it as the “commutative property.” The language used in math instruction should be clear, concise, correct, and consistent, but also student-friendly. Sentence starters and guiding questions can help students practice communicating using newly learned vocabulary.
Timed Activities: Timed activities help students develop automatic fact retrieval, which helps enable them to solve solve multi-step problems and learn more complex ideas. For example, to efficiently add fractions, students should have a solid grasp of basic multiplication — it’s hard to determine the value of 2/3 + 4/5 if calculating 3*5 consumes a lot of mental energy. Activities should be brief (usually 1-5 minutes) and provide real-time feedback, goals for improvement, and steadily increasing item difficulty.
The recommendations in the guide are consistent with DI, not IBL: it contains multiple direct phrases like “a shared list of mathematical terminology” and “[b]reak those into a series of small steps.” The guide is also full of explicit “how-to steps” for teachers. For example, here’s a passage from their recommendation on using the number line:
Demonstrate the location of fractions on the number line, starting with familiar fractions that are less than one. Ask students to fold a strip of paper in half to see two equal parts. Discuss with students how this represents partitioning a 0–1 segment of the number line into two equal parts. Ask students to mark the location of one-half. Then ask them to partition a strip of paper into four equal parts…
And in response to the objection that students should “come up with their own solution,” the authors of the guide write:
By teaching specific solution strategies, you offer students a way to move through the problem-solving process successfully so that eventually they may be able to develop their own solution methods.
It sounds like they’re implicitly referencing the expertise reversal effect — guidance is essential for novices but potentially detrimental for more experienced learners.
3. Computer Science
Given the success of DI in reading and math, let’s consider some possible implications for computer science. I’ll start by saying that even though this post has focused on subjects for younger students, I suspect that CS concepts can be taught much earlier than in college. If a child can learn about parabolas and Shakespeare, I think they can (and should) learn about induction and graphs. So even though phonics and CS instruction are worlds apart in the education system, they might not be as different as they seem.
Mark Guzdial is one of the most well-known people in the CS education research community. In 2009, he wrote a blog post on the phonics of computing education. How can we help students improve their mechanics of programming? Can we create tutorials and drills similar to phonics in reading, worksheets in math, and scales in music? Here are a few ideas he gave:
The syntax of the programming language: For example, students learning Python sometimes make indentation errors, but they’re hard to detect and fix. Perhaps these students would benefit from a tool that focused exclusively on details like these, which exist on a scale that’s smaller than the full activity of programming. Similarly, it might take a while for students learning Java to become fluent in semicolon placement.
How to read code: In a typical piece of code, some parts (e.g., “public static void” in Java) can be safely ignored, but novices sometimes have trouble identifying these parts, so we should teach these things explicitly. (This one’s really analogous to phonics.)
How to tinker with code: Tinkering helps us understand code by making small adjustments and seeing how the output changes. But what adjustments should we make, and what do changes in the output tell us? Experts often learn the answers to these questions implicitly, but perhaps they should be taught explicitly.
Interestingly, the comments section contains some debate that parallels the one between phonics and whole language. In particular, Erik Engbrecht wrote the following:
I just don’t believe that people are really struggling with semicolons, matching curly braces, etc etc. Or at least not people who are ever going to make it.
I do believe, however, that initially dealing with such things can completely destroy any state of flow that the student may be entering, and thus prevent the high-level of concentration that’s needed to program well.
This sounds similar to advocates of whole language who dismiss phonics as “drudgery that prevents children from loving literature.” How can students truly engage in any activity if they get bogged down in a bunch of annoying rules? On the other hand, how can students get anywhere if they aren’t proficient in the actual activity?
I strongly suspect that there’s no clean “theory of everything” when it comes to learning. As I mentioned earlier, I think some situations call for one approach while other situations call for another — the tricky part is determining (a) which situation you’re in and (b) which approach works best for that situation. There are also other learning theories beyond DI and IBL, even just in CS (e.g., constructivism, multiple conceptions); this post isn’t meant to be a staunch defense of Direct Instruction, phonics, or any singular pedagogical idea. (Education is full of debates!)
The first paragraph of this article from 2017, also by Mark Guzdial, nicely summarizes my (current) general impression of how we should teach:
A computing educator has to balance teaching efficiently and motivating the student. Efficient teaching means teaching abstractly, emphasizing practice, and preferring direct instruction over having students “figure it out.” Motivating the student means giving the students authentic situations, real-world complexity, and reasons to practice.
These correspondences aren’t exactly official in some sense, but I’ve seen people draw these connections, and they seem right to me.
You lost me a bit at “To me, these recommendations are more in line with DI than IBL”. I thought there had been an assertion that these were DI strategies and you were disagreeing with it. On several readings I now think that you were classifying these for the first time, and finding them to be more DI. Stronger without the “to me”.
Oh cool! Somebody talked to me on here