Posts tagged ‘teachers’
Larry Cuban is a remarkable educational historian. He’s written an article about why requiring coding is a bad idea, and links it to the history of Logo in the 1980’s. I think #1 is the most important, and is similar to Seymour Papert’s “Why School Reform is Impossible” article and to Roy Pea’s concerns about requiring computing.
The reasons are instructive to current enthusiasts for coding:
1. While the overall national context clearly favors technological expertise, Big Data, and 21st century skills like programming, the history of Logo showed clearly, that schools as institutions have lot to say about how any reform is put into practice. Traditional schools adapt reforms to meet institutional needs.
2. Then and now, schools eager to teach coding , for the most part, catered to mostly white, middle- and upper-middle class students. They were and are boutique offerings.
3. Then and now, most teachers were uninvolved in teaching Logo and had little incentive or interest in doing so. Ditto for coding.
4. Then and now, Logo and coding depend upon the principle of transfer and the research supporting such confidence is lacking.
First the good news: STEM enrollment is up. Then the surprising news: Humanities are not losing students to STEM. Rather, it’s the professional fields like education that are losing enrollment. That makes CS Ed (and other STEM discipline-based education research (DBER) fields) the odd winner-losers. Yay, there are more students, but there will be fewer STEM teachers in the future to teach them.
Policy makers regularly talk about the need to encourage more undergraduates to pursue science and technology fields. New data suggest that undergraduates at four-year institutions in fact have become much more likely to study those fields, especially engineering and biology.
And while much of the public discussion of STEM enrollments has suggested a STEM vs. liberal arts dichotomy (even though some STEM fields are in fact liberal arts disciplines), the new study suggests that this is not the dynamic truly at play. Rather, STEM enrollments are growing while professional field enrollments (especially business and education) are shrinking.
The ComputerWorldK agrees. They claim that the smart students were going into business, then Wall Street collapsed, and now they’re going into CS and that’s why we’re having sky-rocketing enrollments.
The number of computer science graduates will continue to increase. Computer science enrollments rose by nearly 30% in the 2011-12 academic year, and they increased 23% the year before that.
The trend of enrollment increases since 2010 bodes well for a “future increase in undergraduate computing production,” according to the report.
The recession that hit in 2008 sent IT unemployment soaring, but it may have done more damage to the finance sector, especially in terms of reputation. That prompted some educators at the time to predict that the recession might send math-inclined students from the world of hedge funds to computer science.
An important new working paper from the ExploringCS group asks the question: If we achieve CS10K, how do we avoid only having CS5K left after only five years? This is exactly the question that Lijun Ni was exploring in her dissertation on CS teacher identity.
Of the 81 teachers who have participated in the ECS program over the last
five years, 40 are currently teaching ECS in LAUSD. These numbers reveal that we
have “lost” more teachers than we have “retained.” Of the 40 teachers who are
currently teaching the ECS course, 5 of them had a 1-2 year interval in which they
did not teach the course. This means that fully 45 of the 81 teachers who have
participated in the ECS program have experienced a teaching “disruption” which has
ended their participation in the ECS teacher community for a year or longer.
In particular, they ask us to consider the dangers of short-term fixes to long-term problems, which is a point I was trying to make when arguing that we may be 100 years behind other STEM subjects in terms of making our discipline-based education available to all.
In response to scaling up challenges, we can expect a rise of “quick-fix”
solutions that have a potential to undercut progress. One quick-fix “solution” to
address CS teacher shortage or the need for deepened teacher content knowledge
are programs that bring industry professionals to assist teachers in CS classrooms.
While we are interested in learning more about the outcomes of these programs,
because there can be value in students hearing from experts in the field, there are
also risks to having industry professionals take on a teaching role in the classroom
without professional development in effective and relevant pedagogy and belief
systems and equitable practices. Will industry professionals deliver content
knowledge the way they were taught, not having had experience working with the
novice learner? Will they focus on working with the students who think more like
they do, to the neglect of the other students? In short quick fixes like these may
inadvertently perpetuate the persistent divides in the field.
I add to their list of questions: Does bringing in IT professionals reduce the administrative pressure that pushes teachers out of CS? Does it help to create the context and environment that supports CS teachers?
I used this working paper in my post this month for Blog@CACM. Vint Cerf recently gave testimony in the Senate recommending a requirement for CS in all primary and secondary schools. The ECS experience (and Lijun Ni’s work) point toward the need to create a supportive environment for CS teaching if we want to achieve Vint’s recommendation.
Highly recommended read.
At the NCWIT Summit this year, I heard an interesting concern. If CS counts as a mathematics or science course towards high school graduation requirements, will that make CS even less diverse? Should we keep CS as a business topic (elective) where the women and under-represented minorities are?
I took up that question for my Blog@CACM post for this month: Why Counting CS as Science or Math is Not Considered Harmful. I argue that our goal is universal computational literacy, with everyone using computing in every class and everyone taking CS. I don’t really care how it gets a foothold in schools. It was fun to write about Alan Kay, Adele Goldberg, and Andy diSessa, pointing out that they were talking about these ideas a long time before computational thinking.
Gas station without pump’s post on Garth’s complaint “Teaching programming is not getting easier” intrigued me. Garth does a good job of pulling together a lot of the themes of what makes teaching CS hard today. I think that we can improve the situation. I’m particularly interested in learning how to scaffold the development of programming knowledge, and we have to find ways to create professional communities of CS teachers. There are techniques to share (worked examples, peer instruction, pair programming, Parson’s problems, audio tours), and we’re clearly not doing a good job of it yet.
In programming there are 4 homework problems over the period of a week, none of which are “easy”, and all require some problem solving and thinking. There is somewhat of an incremental progression to the problems but that step from written problem to code is always a big one. It is somewhat similar to solving word problems in math, every student’s favorite task. For programming there are no colleagues available that have as much or more experience to pull teaching ideas from, if there are any other programming teachers at all. There are no pedagogical resources anywhere online for teaching strategies. After watching a number (3) of programming teachers teach it seems the teaching strategy is pretty consistent; show and tell and hope.
Premise 1: Teaching is a human endeavor that does not and cannot improve over time.
Premise 2: Human beings are fantastic learners.
Premise 3: Humans don’t learn well in the teaching-focused classroom.
Conclusion: We won’t meet the needs for more and better higher education until professors become designers of learning experiences and not teachers.
Interesting argument linked above, but wrong.
- Premise 1: Teaching does improve with time. Gerhard Fischer published a wonderful piece many years ago that showed how skiing instruction has improved over time, and that the approaches used can be understood in terms of cognitive science.
- Premise 2: Humans are fantastic learners, but as Kirschner, Sweller, and Clark showed, humans learn much better with direct instruction.
- Premise 3: No, no one learns well in a teaching-focused classroom. However, many teachers help their students learn better in a student-centered classrooms.
- The Conclusion doesn’t follow from the premises at all.
My May 2014 Blog@CACM post, “What it takes to be a successful high school computer science teacher” sneaks up on a radical suggestion, that I’ll make explicitly here. High school computer science teachers need to be able to read and trace code. They don’t necessarily need to know much about writing code, and they certainly don’t need to know how to be software developers.
As we are developing our CSLearning4u ebook, we’re reviewing a lot of our prior research on the practices of successful CS teachers. What do we need to be teaching teachers so that they are successful? We don’t hear successful CS teachers talking much about writing code. However, the successful ones read code a lot, while the less-successful ones do not. Raymond Lister has been giving us evidence for years that there’s a developmental path from reading and tracing code that precedes writing code.
Yes, I’m talking about taking a short-cut here. I’m suggesting that our worldwide professional development efforts for high school teachers should emphasize reading and tracing code, not writing code. Our computer science classes do the reverse of that. We get students writing code as soon as possible. I’m suggesting that that is not useful or necessary for high school teachers. It is easier for them to read and trace code first (Lister’s studies) and it’s what they will need to do most often (our studies). We can reduce costs (in time and effort) of this huge teacher development effort by shuffling our priorities and focusing on reading.
(We do know from studies of real software engineers that they read and debug more than they write code. Maybe it would be better for everyone to read before writing, but I’m focusing on the high school teachers right now.)