Barbara Ericson’s 2015 AP CS demographics analysis: Still No African-Americans Taking the AP CS Exam in 9 States
Normally, this is the time of the year when Barb writes her guest post about the AP CS exam-taker demographics. She did the analysis, and you can get the overview at this web page and the demographics details at this web page.
But before we got a chance to put together a blog post, Liana Heitin of EdWeek called her for an interview. They did a nice job summarizing the results (including interactive graphs) at the article linked below.
Some of the more interesting points (from Liana’s article):
No girls took the exam in Mississippi, Montana, or Wyoming. (Though Montana had no test-takers at all, male included, this year. Wyoming, which previously had no students take the test, had three boys take the exam in 2015).
Hawaii had the largest percentage of female test-takers, with 33 percent.
The overall female pass rate went up 3 percentage points, to 61 percent, from the year before.
Twenty-four girls took the test in Iowa, and 100 percent of them passed.”You don’t usually see 100 percent passing with numbers that big,” said Ericson. “Maybe five out of five pass. But 24 out of 24 is pretty cool.”
No African-American students took the exam in nine states: Idaho, Mississippi, Montana, New Hampshire, New Mexico, North Dakota, South Dakota, Utah, and Wyoming. That’s better than last year, though, when 13 states had no African-American test-takers.
Notably, Mississippi has the highest population of African-Americans—about half of the state’s high school graduates last year were black, according to the Western Interstate Commission for Higher Education. Yet of the five AP computer science test-takers, all were white or Asian and male.
Preview for WiPSCE 2015: Usability and usage of interactive features in an online ebook for CS teachers
Next week in London, at WiPSCE 2015, the 10th Workshop in Primary and Secondary Computing Education, Barbara Ericson is going to present the pilot study of our teacher CSP ebook that Steven Moore (undergrad researcher here at Georgia Tech) ran last year. This is the pilot that came before our Spring trial (see post here) and which led to our student and teacher ebooks that we recently released (see post here). The authors of the paper are Barbara, Steven, Brianna Morrison, and me.
Steven’s study had two parts to it. The first was a usability survey comparing three different ebook platforms: Runestone Interactive, Zyante, and CS Circles. You may recall the post here where I invited you to participate in that survey. Runestone did well in the survey, just beating out Zyante, and both were far ahead of CS Circles.
The meat of the paper is the study of 10 teachers who qualified for our study (got less than 40% on a pretest) and read the 8 chapters we had ready for them. Every two chapters, there was a post-test on those two chapters. Some of the findings:
- 50% of the study participants finished all 8 chapters. That’s pretty good, but isn’t directly comparable to MOOC studies because we did offer them a $50 gift card for completing.
- As we expected and designed for, teachers read the books in chunks of time when they could fit it in.
- Those who used the book (e.g., did the Parson’s problems, ran the code, etc.), gained confidence in teaching CS and performed well on the post-tests. This is a big deal! The teachers are not just writing code. They are using a variety of different kinds of learning activities (see our ICER ebook paper) — and successfully learning and gaining confidence. Writing code is not the only way to learn CS. This has been one of the more controversial hypotheses. Many CS teachers believe that apprenticeship is the only way to learn CS, but we believe that we can successfully use a range of pedagogical practices.
Barbara did an extensive log file analysis of the participants, and we learned a lot from that. We
learned where our books were not usable, e.g., when participants skipped over interactive features, or when they used the features wrong (e.g., clicking “Check Me” on a Parson’s problem, without ever moving pieces around). We used these findings in designing the current ebooks.
This paper is exciting for us — it’s the first where we test our design claims.
There are only a couple of universities in Georgia where you can get a CS teaching endorsement (a kind of credential that is an add-on to an initial certification). In both of them, you have to have a CS methods class, where students learn how to teach CS. One of them needed a CS methods course taught, but didn’t have anyone available to teach it. The problem was that it was needed by a single student (these endorsement programs are woefully undersubscribed). I offered to teach it — though not officially, since I’m a GT professor and not a professor at these other schools. So, someone else was signed up to be the instructor-of-record, and I ran the course, all on-line with weekly Skype chats.
Folks might be interested in what’s in a Methods course, so I’m sharing my draft syllabus here. Since there was only one student, I made up a syllabus to submit to check that it met the requirements of the course, and we didn’t update it afterwards. I make no claims about quality of the course. It was a class for one student to meet a requirement, and I wanted the experience of teaching a CS methods course. It did meet all the requirements of the program (which were more prescribed and substantial than most CS courses I teach). Not all the links here are live — some went to servers inside firewalls, and others were sent out via email.
Syllabus for CS Methods Course
- Be able to describe use and when one should use different CS teaching approaches like live coding, peer instruction, pair programming, worked examples, and kinesthetic learning activities.
- Be able to describe and diagnose common student misconceptions, e.g., with assignments, with while vs. if, and so on.
- Be able to describe approaches to teaching computer science, including constructionist, objects-first, functions-first, media computation.
- Write a lesson plan to teach a CS topic for a specific grade level, including assessments.
Assignments (and distribution for final grade):
- Reading reflections (4): 25% of grade
- Lesson plan: 25%
- Exam and grading rubric: 15%
- HW assignment design and grading rubric: 15%
- Project: Create all the teaching material for a single unit within a Computing Pathway class, including lessons plans, homework assignments, grading rubrics, and tests: 30%
- Why is learning to program hard? Read Guzdial chapter from Fincher & Petre and Robins, Rountree, and Rountree.
- Write Reading Reflection #1: Do you agree with the challenges to learning programming that you read there? What additional challenges have you seen?
- Read Juha Sorva appendix A. Link to whole thing.
- Discuss: How would you identify these misconceptions? How would correct them?
- Read a paper on Pair Programming (probably this one).
- Write Reading Reflection #2: Why do you think Pair Programming works as well as it does in this study? Do you think it would work as well in a high school setting?
- Read a paper on Peer Instruction: Pick any one that you like on this site.
- Review KLA website.
- Read four blog posts on worked examples in classroom from this site.
- Discuss: Peer instruction, KLA, worked examples, gesture: When are they useful and when aren’t they?
- Two readings on CS assessment: On concept inventories, and how do we assess CS.
- Write Reading Reflection #3: These papers are both undergraduate computer science. How would it be different when accessing computer science at the high school level? Would the issues be the same or different?
- How we design CS curricula.
- Discuss: Which of these approaches would work best for high school students and why? When would one work better than another?
- Write Reading Reflection #4: Based on all of these readings, come up with a philosophy of teaching K-12 computer science. Pick a grade range you prefer (elementary, middle school, secondary), and describe: What do you think ought to be taught? How do you think it ought to be taught? How do you think it ought to be assessed?
- Discuss the reflection, and pick a topic to write a lesson plan on
- Write a lesson plan: How would you teach the CS topic?
- Discuss afterwards.
- Write a homework description and grading rubric: What would you want students to do, to learn this topic? What misconceptions would you expect? How would you assure yourself they got it right?
- Discuss afterwards.
- Write an exam to test knowledge of that topic and the grading rubric for that exam.
- Discuss afterwards
- Discuss Planning for project. What worked, and what didn’t work? Are there additional things you need to know?
- Week to do additional reading, or to identify a topic for the project.
- Work week on Project
Week 15: Project completed
- Project: Create all the teaching material for a single unit within a Computing Pathway class, including lessons plans, homework assignments, grading rubrics, and tests
The below-linked article does a good job of considering the argument about whether everyone can learn to program, and comes to the same conclusion that I do — a CS teacher must always believe that everyone can learn to program.
Indeed, one can find a good number of opinionators weighing in on the subject. In “Separating Programming Sheep from Non-Programming Goats,” Stack Exchange co-founder Jeff Atwood cites Bornat’s initial paper and concludes, “the act of programming seems literally unteachable to a sizable subset of incoming computer science students.” Linux creator Linus Torvalds has been quoted as saying, “I actually don’t believe that everybody should necessarily try to learn to code” — although, he does propose that people be exposed to it to see if they have “the aptitude.” Clayton Lewis of the University of Colorado at Boulder conducted a survey in which 77% of responding computer science faculty strongly disagreed with the statement “Nearly everyone is capable of succeeding in the computer science curriculum if they work at it.” As a “bright-eyed beginner” (with a scant 15 years of introductory programming teaching under my belt), it’s hard for me to accept the assertion that there are “some who can’t.” Such reasoning smacks of elitism and prejudice, even if such attitudes aren’t expressed consciously.
Of course, I’ll be the first to admit that my own opinion rests heavily on my own preconceptions: I’ve always had that “Montessori feeling” — every interested student should be given a chance to try, and sometimes fail, in a supportive environment.So, rather than give up on some, shouldn’t educators themselves keep trying? The inverse to the question “are there some students who can’t learn?” is this question, “are there some students whom our (current) teaching methods can’t reach?” The first question by itself implies a “yes,” and thus closes a door on some students. The second question opens up a world of inquiry: if basic coding concepts are truly so simple (as they truly are once the abstraction is understood), what do we need to do to bring the hard cases home?
Human students need active learning and Econs learn from lecture: NYTimes Op-Ed in defense of lecture
I’m sympathetic to the author’s argument (linked below), that being able to understand an argument delivered as a lecture is difficult and worthwhile. Her characterization of active learning is wrong — it’s not “student-led discussion.” Actually, what she describes as good lecture is close to good active learning. Having students answering questions in discussion is good — but some students might disengage and not answer questions. Small group activities, peer led team learning, or peer instruction would be better to make sure that all students engage. But that’s not the critical flaw in her argument.
Being able to listen to a complicated lecture is an important skill — but students (at least in STEM, at least in the US) don’t have that skill. We can complain about that. We can reform primary and secondary schooling so that students develop that skill. But if we want these students to learn, the ones who are in our classes today, we should use active learning strategies.
Richard Thaler introduced the term “Econs” to describe the rational beings that inhabit traditional economic theory. (See a review of his book Misbehaving for more discussion on Econs.) Econs are completely rational. They develop the skills to learn from lecture because it is the most efficient way to learn. Unfortunately, we are not econs, and our classes are filled with humans. Humans are predictably irrational, as Daniel Ariely puts it. And there’s not much we can do about it. In his book Thinking, Fast and Slow, Daniel Kahneman complains that he knows how he is influenced by biases and too much System 1 thinking — and yet, he still makes the same mistakes. The evidence is clear that the students in our undergraduate classes today need help to engage with and learn STEM skills and concepts.
The empirical evidence for the value of active learning over lecture is strong (see previous post). It works for humans. Lecture probably works for Econs. If we could find enough of them, we could run an experiment.
In many quarters, the active learning craze is only the latest development in a long tradition of complaining about boring professors, flavored with a dash of that other great American pastime, populist resentment of experts. But there is an ominous note in the most recent chorus of calls to replace the “sage on the stage” with student-led discussion. These criticisms intersect with a broader crisis of confidence in the humanities. They are an attempt to further assimilate history, philosophy, literature and their sister disciplines to the goals and methods of the hard sciences — fields whose stars are rising in the eyes of administrators, politicians and higher-education entrepreneurs.
A similar argument to mine is below. This author doesn’t use the Humans/Econs distinction that I’m using. Instead, the author points out that lecturers too often teach only to younger versions of themselves.
I will grant that nothing about the lecture format as Worthen describes it is inherently bad. But Worthen’s elegy to a format that bores so many students reminds me of a bad habit that too many professors have: building their teaching philosophies around younger versions of themselves, who were often more conscientious, more interested in learning, and more patient than the student staring at his phone in the back of their classrooms.
The headline that a professor wants to double the number of CS teachers is cool, but as I dug into the piece, I grew jealous. Wisconsin has CS teacher certification! (Even if “confused, disparate, and sometimes absurd.”) They have pre-service teacher programs! They need more CS Teaching Methods classes — I’ve taught CS teaching methods! Are they hiring? (Oh, wait — I’ve heard about what’s happening to Wisconsin state universities.) Except for that university part, Wisconsin sounds like it has it good!
The second piece of the plan consists of easing the process for computer science teachers to receive their license. Getting certified is difficult, according to Brylow. According to one report from the Computer Science Teachers Association, the process is described as “confused, disparate, and sometimes absurd.”UW-La Crosse and UW-Whitewater are the only universities left in the state that offer programs to get certified, after many universities began dropping the program in the 1990s. “Whitewater has graduated three computer science teachers in the past five years and La Crosse has graduated zero in the past five years,” Brylow said. “So we identified that one of the problems is nobody knows how to teach this one critical course called the Computer Science Teaching Methods course.
I’ve written responses to comments like Atwood’s before. His perspective on “coding” is too limited, and he isn’t realizing that being a user and being a programmer is where most people will be (see the “fat line” blog post here). That “provide them plenty of structured opportunities to play with hardware and software” is a pretty good definition of one kind of “teaching kids ‘computer science.'” We need that. But the kids who only need opportunities to “play” in order to learn tend to be highly privileged (see the “rich boys” blog post here). Nobody wants kids to just “type in pedantic command words in a programming environment.” That’s a good definition of poor computing teaching. We need good teachers who know how to support a range of students with different kinds of scaffolding.
So what Atwood is really saying that we need good CS teaching. Yup, you need a lot of that in NYC — I agree.
If you want your kids to have a solid computer science education, encourage them to go build something cool. Not by typing in pedantic command words in a programming environment, but by learning just enough about how that peculiar little blocky world inside their computer works to discover what they and their friends can make with it together. We shouldn’t be teaching kids “computer science.” Instead, we should provide them plenty of structured opportunities to play with hardware and software. There’s a whole world waiting to be unlocked.