Is there a Geek Gene? Are CS grades bi-modal? Moving computing ed research forward

This month’s Communications of the ACM published Elizabeth Patitsas’s ICER paper about bimodality in CS grades (or rather, the lack thereof) as a research highlight, Evidence that Computer Science Grades are not Bimodal. It’s a big deal to have computing education in this position in the ACM flagship publication, and thanks to Shriram Krishnamurthi for his efforts in making this happen.

I wrote about Elizabeth’s paper when it was originally published at ICER at this blog post. Elizabeth wrote a guest blog post here on these topics (see here). These are important issues — Wired has just published an article talking about the Geek Gene with a great discussion of Betsy DiSalvo’s work (see post here about some of Betsy’s work).

I wrote the introductory page to the article (available here). I point out that Elizabeth’s article doesn’t end the debate, but it does move forward how we address questions about how we teach and how students learn:

This paper does not prove there is no Geek Gene. There may actually be bimodality in CS grades at some (or even many) institutions. What this paper does admirably is to use empirical methods to question some of our long-held (but possibly mistaken) beliefs about CS education. Through papers like these, we will learn to measure and improve computing education, by moving it from folk wisdom to evidence-based decision-making.

The problem with sorting students into CS classes: We don’t know how, and we may institutionalize inequity

One of the more interesting features of the ACM SIGCSE ITiCSE (Innovation and Technology in CS Education) conference are “working groups” (see description here). Groups of attendees from around the world work together before and at the conference on an issue of interest, then publish a report on what happened. This is the mechanism that Mike McCracken used when he organized the first Multi-Institutional, Multi-National (MIMN) study in CS Ed (see paper here). This year’s Working Group #9 caught my eye (see list here).

The description of what the group wants to explore is interesting: How can we measure what will lead to success in introductory computer science?

The main issues are the following.

• The ability to predict skill in the absence of prior experience
• The value of programming language neutrality in an assessment instrument
• Stigma and other perception issues associated with students’ performance, especially among groups underrepresented in computer science

It’s a deep and interesting question that several research groups have explored. Probably the most famous of these is the “The Camel has Two Humps.” If you read that paper, be sure to read Caspersen et al’s (unsuccessful) attempt to replicate the results (here), Simon’s work with Dehnadi and Bornat to replicate the results (again unsuccessful, here), and then finally the retraction of the original results (here). Bennedsen and Caspersen have a nice survey paper about what we know about predictive factors from ICER 2005, and there was a paper at SIGCSE 2019 that used multiple data sources to predict success in multiple CS courses (here). The questions as I see it are (a) what are the skills and knowledge that improve success in learning to program, (b) how can we measure to determine if they are there, and (c) how can we teach those skills explicitly if they are not.

Elizabeth Patitsas explored the question of whether there are innate differences between students that lead to success or failure in introductory CS (see paper here). She does not prove that there is no so-called Geek Gene. We can’t prove that something does not exist. She does show that (a) that grades at one institution over many years are (mostly) not bimodal, and (b) some faculty see bimodal grade distributions even if the distribution is normal. If there was something else going on (Geek Gene, aptitude, whatever), you wouldn’t expect that much normality. So she gives us evidence to doubt the Geek Gene hypothesis, and she gives us a reasonable alternative hypothesis. But it isn’t definitive proof — that’s what Ahadi and Lister argued at ICER 2013. We have to do more research to better understand the problem.

Are Patitsas’s results suspect because they’re from an elite school? Maybe. Asking that question is really common among CS faculty — Lecia Barker found that that’s one of the top reasons why CS faculty ignore CS Ed research. We discount findings from places unlike ours. That’s why Multi-Institutional, Multi-National (MIMN) is such a brilliant idea. They control for institutional and even national biases. (A MIMN study showing the effectiveness of Peer Instruction is in the top-10 SIGCSE papers list.)

In my research group, we’re exploring spatial reasoning as one of those skills that may be foundational (though we don’t yet know how or why). We can measure spatial reasoning, and that we can (pretty easily) teach. We have empirically shown that wealth (more specifically, socioeconomic status (SES)) leads to success in computing (see this paper), and we have a literature review identifying other privileges that likely lead to success in CS (see Miranda Parker’s lit review).

I am concerned about the goals of the working group. The title is “Towards an Ability to Direct College Students to an Appropriately Paced Introductory Computer Science Course.” The first line of the description is:

We propose a working group to investigate methods of proper placement of university entrance-level students into introductory computer science courses.

The idea is that we might have two (or more) different intro courses, one at a normal pace and one at a remedial pace. The overall goal is to meet student needs. There is good evidence that having different intro courses is a good practice. Most institutions that I know that have multiple introductory courses choose based on major, or allow students to choose based on interest or on expectations of abilities. It’s a different thing to have different courses assigned by test.

If we don’t know what those skills are that might predict success in CS, how are you going to measure them? And if you do build a test that sorts students, what will you actually be sorting on?  It’s hard to build a CS placement test that doesn’t actually sort on wealth, prior experience, and other forms of privilege.

If the test sorts on privilege, it is institutionalizing inequity. Poor kids go into one pile, and rich kids go into the other. Kids who have access to CS education go into one pile, everyone else into another.

Why build the test at all?  To build a test to sort people into classes presumes that there are differences that cannot be mitigated by teaching. Building such a test presumes that there is a constant answer to “What does it take to succeed in CS1?” If we had such a test, would the results be predictive for classes that both use and don’t use pair programming? Peer instruction? Parsons problems?

I suggest a different perspective on the problem.  We can get so much further if we instead improve success in CS1. Let’s make the introductory course one that more students will succeed in.

There’s so much evidence that we can improve success rates with better teaching methods and revised curriculum. Beth Simon, Leo Porter, Cynthia Lee, and I have been teaching workshops the last four years to new CS faculty on how to teach better. It works — I learned Peer Instruction from them, and use it successfully today. My read on the existing literature suggests that everyone benefits from active learning, and the less privileged students benefit the most (see Annie-Murphy Paul’s articles).

One of the reasons why spatial reasoning is so interesting to explore is that (a) it does seem related to learning computing and (b) it is teachable.  Several researchers have shown that spatial skills can be increased relatively easily, and that the improved skills are long-lasting and do transfer to new contexts. Rather than sort people, we’re better off teaching people the skills that we want them to have, using research-informed methods that have measurable effects.

Bottom line: We are dealing with extraordinary enrollment pressures in CS right now. We do need to try different things, and multiple introductory courses is a good idea. Let’s manage the enrollment with the best of our research results. Let’s avoid institutionalizing inequities.

Belief in the Geek Gene may be driven by Economics and Educational Inefficiency, plus using blocks to cross language boundaries

I visited China in the first part of May. I was at Peking University (PKU) in Beijing for a couple days, and then the ACM Celebration of the Turing Award in China (TURC) in Shanghai. I mentioned the trip in this earlier blog post. I wrote a blog post for CACM on a great panel at TURC. The panelists discussed the future of AI, and I asked about the implications for computing education. Are we moving to a future where we can’t explain to students the computing in their daily lives?

A highlight of my trip was spending a day with students and teachers at PKU. I taught a seminar with 30+ advanced undergraduates with Media Computation (essentially doing my TEDxGeorgiaTech talk live). It was great fun. I was surprised to learn that several of them had learned programming first in high school in Pascal. Pascal lives as a pedagogical programming language in China!

Perhaps the most striking part of my seminar with the undergraduates was how well the livecoding examples worked (e.g., I wrote and manipulated code as part of the talk).  All the PKU students knew Java, most knew C++, some knew Python — though I knew none of that when I was planning my talk. I wanted to use a tool that would cross programming language boundaries and be immediately understandable if you knew any programming languages. I used a blocks-based language.  I did my livecoding demonstration entirely in GP. I tested their knowledge, too, asking for predictions (as I do regularly, having read Eric Mazur’s work on predictions before demos) and explanations for those predictions.  They understood the code and what was going on. The funky sound and image effects cross language barriers.  Students laughed and oohed at the results.  Isn’t that remarkable that it worked, that I could give a livecoding demonstration in China and get evidence that the students understood it?

The most interesting session at PKU was talking with faculty interested in education about their classes and issues. I’ve always wondered what it’s like for students to learn programming when English is not their native language, and particularly, when the characters are very different. I asked, “Is it harder for your students to learn programming when the characters and words are all English?” The first faculty to speak up insisted that it really wasn’t an issue. “Our students start learning English at age 6!” said one. But then some of the other faculty spoke up, saying that it really was a problem, especially for younger students. In some middle schools, they are using Squeak with Chinese characters. They told me that there was at least one programming language designed to use Chinese characters, but the other faculty scoffed. “Yi is not a real programming language.” There was clearly some disagreement, and I didn’t follow all the nuances of the argument.

Then the Geek Gene came up in the conversation. One of the most senior faculty in the room talked about her challenges in teaching computer science. “Some students are just not suited to learning CS,” she told me. I countered with the evidence of researchers like Elizabeth Patitsas that there is no “Geek Gene.” I said, “We have no evidence that there are students who can’t learn programming.” She had an effective counter-argument.

“We do not have all the time in the world. We cannot learn everything in our lifetime. How much of a lifetime should a student spend learning programming? There are some students who cannot learn programming in the time available. It’s not worth it for them.”

I had not thought of the Geek Gene as being an economic issue. Her argument for the Geek Gene is not necessarily that students cannot learn programming. They may not be able to learn programming in the time available and using the methods we have available. This is not Geek Gene as only some students can learn to program. This is Geek Gene as economic limitation — we can’t teach everyone in the resources available.

I have an answer to that one. Want to reach more students? Either expand the time it will take to teach them, or use more effective methods!  This is the same response that I had offered to my colleague, as I described in an earlier blog post.

That insight gave me a whole new reason for doing our work in efficient CS education, like the greater efficiency in using subgoal-based instruction. The work of Paul Kirschner and Mike Lee & Amy Ko also emphasizes more CS learning in less time. If we can teach the same amount of CS in less time, then we can expand the number of students who can learn enough CS with a given amount of resource (typically, time). If we can’t convince teachers that there is no Geek Gene, maybe we can give them more effective and efficient teaching methods so that they see fewer students who don’t seem have the Geek Gene, i.e., who can learn enough CS in a single semester.

Below, evidence I was really at TURC

Source of the “Geek Gene”? Teacher beliefs: Reading on Lijun Ni, Learning from Helenrose Fives on teacher self-efficacy

I discovered the below quoted post when I was looking up a paper by my former student, Lijun Ni.  It’s nice to see her work getting recognized and reviewed!  I talked a lot about her work when I was talking to PhD students at the University of Oldenburg program — Lijun has studied the beliefs of CS teachers, and that’s super important.

One of the other international guests at the Oldenburg program I attended last month (see post here) was Helenrose Fives who has literally written the book on teacher beliefs (see Amazon reference).  Several of the PhD students who presented their research talked about student teachers having lower self-efficacy after actually being in the classroom, less commitment to ideals like inquiry learning, and less belief that students can learn.  Helenrose said that that’s really quite common.  Teachers have a high level of self-efficacy (“I can teach using novel approaches that will really help students learn!”) before they enter the classroom, and that sense of self-efficacy falls off a cliff once they face the reality of the classroom.  The self-efficacy rises over time (up and down, but mostly up) but never reaches the optimism of before teachers enter the classroom.

I talked to Helenrose about what her work means for University CS teachers.  In general, the work she describes is about school teachers, not faculty.  She agreed that it’s possible for University CS teachers to have high self-efficacy even if they are not successful teachers, because University teachers define self-efficacy differently than school teachers.  School teachers are responsible for student learning.  They know individual students.  They actually know if they are successful in their teaching or not (in terms of student learning and engagement).  University teachers tend to have larger classes, and they tend to teach via lecture.  They usually have little knowledge of individual student learning and engagement.  Their sense of self-efficacy may arise from their ability to succeed at their task, “I can give great lectures. (Almost nobody falls asleep.)  I can manage huge classes.”  Where they do have knowledge of learning and evidence of ineffective teaching, they may simply decide that it’s the student’s fault. Perhaps this is where the Geek Gene is born.

Here’s a hypothesis: If a University teacher has high self-efficacy (great confidence in his or her teaching ability) and sees evidence of students not learning, it’s rational for that teacher to believe that the problem lies with the students and that the problem is innate — beyond the ability of the teacher to improve it.

 In the first study, Ni interviewed teachers about their identity in order to establish what strengths and weaknesses are common in high school computer science teachers. She found that the teaching identity of computer science teachers is largely underdeveloped compared to teachers in other fields, and that often computer science teachers prefer to identify as a math teacher or a business teacher, rather than a computer science teacher.

Further, she found that high school computer science teachers generally do not have any sort of teaching support community to turn to, because they are often the only computer science teacher at their school.

All of these problems combine to keep computer science teachers from developing a strong teaching identity centered in the computer science field. Instead, we have teachers with low commitment levels to the field training our next generation of programmers in basic computing skills that are generally unrelated to the field of computer science itself.

via Reading Lijun Ni | computing education.

Why nerd culture must die: Not everyone can teach themselves, and we have to welcome diversity

An interesting argument, with implications for computing education.

• Many people in nerd culture are self-taught — there were few courses in the early days, and people just figured it out.  If we want computing to grow, broaden, and diversify, we have to start teaching this stuff, and not only value those who are self-taught.
• We have to stop insulting our students’ learning.  I told the story in my CS Education Zoo interview of a teacher (at Georgia Tech, I’m sorry to say) who asked everyone who took Python as their first language to raise their hand.  He then told them, “Python is a terrible language.  You need to forget everything you learned if you’re going to learn Java.”  That’s classic nerd culture — dissing the languages and tools of others, of those not in your “in” group.All kinds of CS learning leads to developing expertise. That kind of insult says to women and under-represented minority students, who may already be wondering if they belong (see imposter syndrome), “And you know even less than you thought.”

If we went to get beyond “nerd culture,” then we have to take seriously the welcoming and education of new-comers to our field.

And that’s where the problem lies. We’re still behaving like the rebel alliance, but now we’re the Empire. We got where we are by ignoring outsiders and believing in ourselves even when nobody else would. The decades have proved that our way was largely right and the critics were wrong, so our habit of not listening has become deeply entrenched. It even became a bit of a bonding ritual to attack critics of the culture because they usually didn’t understand what we were doing beyond a surface level. It didn’t used to matter because nobody except a handful of forum readers would see the rants. The same reflex becomes a massive problem now that nerds wield real power. GamerGate made me ashamed to be a gamer, but the scary thing is that the underlying behavior of attacking critics felt like something I’d always seen in our culture, and tolerated. It only shocked me when it was scaled up so massively into rape and death threats, and I saw mainstream corporations like Intel folding in the face of the pressure we can bring to bear.

via Why nerd culture must die « Pete Warden’s blog.

Teaching Computer Science Better to get Better Results

This is my third blog post in a series inspired by a thread in the SIGCSE-Members list and by the Slate article which argued that “Practice doesn’t make perfect.” Macnamara et al did a meta-analysis of studies of expertise, and found that a relatively small percentage of variance in expertise can be explained through hours of practice. The Slate authors argue that this implies that genetics explains the rest of the variance.

• In the first post (see here), I argued that the practice+genetics is too simple to explain expertise. First, practice can be deliberate, lazy, or teacher-led. Second, there is experience that leads to expertise which is between genetics and practice. The most significant flaw of both Macnamara et al. and Ericsson et al. is ignoring teaching.
• In the second post (appearing yesterday in Blog@CACM), I addressed a claim in the SIGCSE-Members list that programmers are “wired” differently than others. Most CS teachers agree with the Slate authors, that students can NOT be more successful with more work. The evidence that better teaching leads to better learning is overwhelming. In fact, there is significant evidence that teaching can even overcome genetic/innate-ability differences.

Lots of CS teachers believe in the Geek Gene Hypothesis, and for good reason. It’s frustrating to have seemingly no impact on some, especially the lower-end, students. Even the award-winning Porter, Zingaro, and Lister paper points out that the earliest assessments in the class they studied correlate very highly with the final grade. Gas Station without Pumps voiced a similar sentiment in his blog post in response to the Slate article:

But the outcomes for individual students seem to depend more on the students coming in than on what I do.  Those students who come in better prepared or “innately” smarter progress faster than those who come in behind, so the end result of the teaching is that differences among the students are amplified, not reduced. Whether the differences in the students coming in are due to prior practice, prior teaching, or genetics is not really knowable, but also not really relevant.

I agree. It’s not really knowable where the difference comes from and it’s not really relevant. The point of my Blog@CACM post is: we can do better. If we can teach spatial ability and subitizing, two skills that have a much stronger claim to being innate than programming, then we can certainly teach people to program better.

If we follow common practice and it’s unsuccessful, it’s not surprising that we think, “I tried. I explained carefully. I gave interesting assignments. I gave good feedback. It’s got to be an innate trait. Some students are just born wired to program.”

I watch my children taking CS classes, along with English, Chemistry, Physics, and Biology classes. In the CS classes, they code. In the other classes, they do on-line interactive exercises, they write papers, they use simulations, they solve problems by-hand. Back in CS, the only activity is coding with feedback. If we only have one technique for teaching, we shouldn’t be surprised if it doesn’t always work

Here’s a reasonable hypothesis: We get poor results because we use ineffective teaching methods. If we want to teach CS more effectively, we need to learn and develop better methods. If we don’t strive for better methods, we’re not going to get better results.

A first step is to be more methodical with how we choose methods. In a 2011 paper by Davide Fossati and me (see here), we found that CS teachers generally don’t use empirical evidence when making changes in how we teach. We act from our intuition, but our students aren’t like us, and our intuition is not a good indicator of what our students need.

Next, we need to experiment with more methods. We want to get to a place where we identify known problems in our students’ understanding, and then used well-supported methods that help students develop more robust understandings. We probably don’t have a wide range of different techniques for teaching assignment, iteration, recursion, and similar concepts? We should try well-supported techniques like pair programming, peer instruction, or Media Computation (see CACM article on these). We should try to expand our techniques repertoire beyond simply grinding at code. We could try techniques like worked examples, Problets, CodingBat, games with learning outcomes like Wu’s Castle, multiple choice questions like in Gidget, the Parson’s Problems in the Runestone Interactive ebooks, or even computing without computers as in CS Unplugged.

We do not make it easy for CS teachers to pick up new, better, more proven methods. Sure, there are the SIGCSE Symposium proceedings, but that’s not a systematic presentation of what to use when. This is on the CS education research community to do better. But it’s also on the CS teaching community to demand better, to seek out better methods and studies of techniques.

If we taught better, there are a lot of problems in CS that we might impact. We might bring in a more diverse group of students. We might make our current students more successful. We might change attitudes about computing. Perhaps most importantly, maybe we as teachers will come to believe that we can teach anyone to program.

The 10K Hour Rule: Deliberate Practice leads to Expertise, and Teaching can trump Genetics

A recent article in Slate (see here) suggests that practice may not lead to expertise, that the “10,000 hour rule” is wrong. The “10,000 hour rule” was popularized by Malcolm Gladwell in his book Outliers (see excerpt here), but really comes from an important paper by K. Anders Ericsson and colleagues, “The Role of Deliberate Practice in the Acquisition of Expert Performance.” Ericsson claimed that 10,000 hours of deliberate practice results in expert-level performance.

The Slate article is based mostly on a new meta-analysis (see here) by Macnamara, Hambrick (also a co-author on the Slate article), and Oswald which reviewed and combined studies on expertise. They found that practice always was positively correlated with better performance, but did not explain all of (or even most of) the difference in expertise between study participants. The Slate article authors suggest, then, that deliberate practice is not as important as genetics or innate talent.

Deliberate practice left more of the variation in skill unexplained than it explained…There is now compelling evidence that genes matter for success, too…What all of this evidence indicates is that we are not created equal where our abilities are concerned.

The paper and article make two big mistakes that leave the “10,000 hour rule” as valid and valuable. The first is that practice is not the same as deliberate practice, and the second is that the fallback position can’t be genetics/innate talent. In general, their argument hinges on practice hours all being of equal value, which shows a lack of appreciation for the role of teaching.

Practice is not the same as deliberate practice

Ericsson was pretty clear in his paper that all practice is not created equal. Deliberate practice is challenging, focused on the skills that most need to be developed, with rapid feedback. (Here’s a nice blog post explaining deliberate practice.) Simply putting in 10,000 hours of practice in an activity does not guarantee expertise. Ericsson and the Slate authors would be in agreement on this point.

I’m sure that we’ve all seen musicians or athletes (and if we’re honest, we’ve probably all been like those musicians or athletes) who sometimes just “phone it in” during practice, or even during a game. I used to coach my daughters’ soccer teams, and I can absolutely assure you that there were hours in games and rehearsals where some of my players really didn’t make any progress. They found ways of getting through practice or games without really trying.

In the Macnamara paper, whether practice was “deliberate” or not was determined by asking people. They collected practice logs, surveys, and interviews. The participants in the studies self-reported whether the practice was deliberate. Imagine someone telling the interviewer or writing in their log, “Yeah, well, about 5,000 of those 10,000 hours, I was really lazy and not trying very hard.”  It’s impossible to really distinguish practice from deliberate practice in this data set.

The bottom-line is that the Macnamara study did not test Ericsson’s question. They tested a weak form of the “10,000 hour rule” (that it’s just “practice,” not “deliberate practice”) and found it wanting. But their explanation, that it’s genetics, is not supported by their evidence.

Genetics/Innate starts at birth, no later

The Slate authors argue that, if practice doesn’t explain expertise, then it must be genetics. They cite two studies that show that identical twins seem to have similar music and drawing talent compared to fraternal twins. But that’s correlation and doesn’t prove causation — there may be any number of things on which the identical twins aren’t similar. (See this great Radiolab podcast exploring these kinds of miraculous misconceptions.)

If you’re going to make the genetics/innate argument, you have to start tracking participants at birth. Otherwise, there’s an awful lot that might add to expertise that’s not going to get counted in any practice logs.

I took classes on how to coach soccer. One of the lessons in those classes was, “It’s a poor coach who makes all practices into scrimmage.” Rather, we were taught to have students do particular drills to develop particular skills. (Sound like deliberate practice?) For example, if my players were having trouble dribbling, I might have them dribble a ball in a line around cones, across distances, through obstacles.

Can you imagine a child who one day might play in a soccer team with official practices — but before those practices and perhaps even before joining a team might dribble a ball around the neighborhood? Wouldn’t that be developing expertise? And yet, it wouldn’t be counted in player logs or practice hours. A kid who did lots of dribbling might come into a team and seem like a superstar with all kinds of innate talent. One might think that the kid had the “Soccer gene.”

To start counting hours-towards-expertise anything later than birth is discounting the impact of learning in the pre-school years on up. We know that pre-school years make a difference (see this website that Diana Franklin sent me, and the argument for pre-school in this recent Freakonomics podcast). A wide variety of activities can develop skills that can be influence expertise. If you don’t start tracking students from birth, then it’s hard to claim that you’ve counted in the practice log everything that’s relevant for expertise.

The claim that expertise is determined at birth is a common claim among CS educators. Most CS teachers to whom I’ve asked the question are convinced some people “can’t” learn to code, that it’s genetic or innate to learn programming. That’s where the myth of the “Geek Gene” came from (Raymond Lister has written several times on that). Couldn’t it be that there are dribbling-around-the-neighborhood activities that lead toward CS expertise? Consider the famous pre-programming activity of writing the instructions out for making a peanut-butter-and-jelly sandwich (like here). If we believe that that kind of practice helps to develop CS expertise, then other “writing instructions out” activities might lead towards CS expertise. Maybe people who seem to have genetic/innate ability in CS just did a lot of those kinds of activities before they got to our classes.

The clock on developing expertise doesn’t start when students walk through our door.

Bigger than P=NP: Is teaching > genetics?

In the end, it’s very difficult to prove or disprove that genetics accounts for expertise in cognitive skill. I don’t think Macnamara et al. settled the score. But my point about deliberate practice actually points to a much bigger issue.

Teachers Matter is the two word title of a 2012 OECD report (available here). There is a difference between great teachers and poor teachers, and the difference can be seen in terms of student performance. If you believe that (and there’s gobs of evidence that says you should), then it seems obvious that all practice is not created equal. Hours spent in practice with a good teacher are going to contribute more to expertise than hours spent without a teacher. Look back at that definition of “deliberate practice” — who’s going to pick the activities that most address your needs or provide the immediate feedback? The definition of deliberate practice almost assumes that there’s going to be teacher in the loop.

An open question is just how far we can get with excellent teaching. How much can we use teaching to get beyond genetic disparities? Is teaching more powerful than genetics? That’s an important question, and far more important than the classic CS question whether P=NP. I believe that there are limits. There are genetic problems that teaching alone can’t address. But we don’t know what those limits are.

We certainly have evidence that we can use teaching to get past some differences that have been chalked up to genetics or being innate. Consider the fact that men have better spatial skills than women. Is it innate, or is it learned? It’s not clear (see discussion on that here). But the important point is: it doesn’t matter. Terlecki, Newcombe, and Little have found that they can teach women to perform as well as men on visual skills and that the improvements in spatial ability both transfers and persists (see the journal article version here). The point is that spatial skills are malleable, they can be developed. Why should we think that other cognitive skills aren’t? The claims of the Slate authors and Macnamara et al ignore the power of a great teacher to go beyond simple rote practice to create deliberate opportunities to learn. The words teach, teacher, and teaching don’t appear in either article.

Here’s my argument summarized.  The Slate authors and Macnamara et al. dismiss the 10K hour rule too lightly, and their explanation of genetic/innate basis for expertise is too simple.  Practice is not the same as deliberate practice, or practice with a teacher. Expertise is learned, and we start learning at birth with expertise developing sometimes in ways not directly connected to the later activity. The important part is that we are able to learn to overcome some genetic/innate disparities with good teaching. We shouldn’t be giving up on developing expertise because we don’t have the genes. We should be thinking about how we can teach in order to develop expertise.

Accounting for the Two Humps

One of the features of CS1 outcomes that has had teachers perplexed for years is the “Two Humps” phenomenon: Some students really get it, and some don’t.  Grade curves for CS1’s typically have two humps, one for each group of students.  What causes that?  The mythical “Geek Gene” is one explanation.

Anthony Robins has an alternative explanation.  He thinks that it’s because everything we do in intro programming builds on the earlier stuff.  If you ever get behind, you’re toast — you can’t do the later homework without getting the earlier homework right.

Michael Kölling has built on Anthony’s explanation to develop a new way of teaching his CS1, which he calls Quality-oriented teaching of programming. The idea is to think about succeeding in the class in terms of number of programs completed, rather than achieving a passing grade on all or most homework assignments.

I haven’t read Anthony’s paper yet, but am looking forward to it.  I’ve tended to believe that the two humps are caused by a priori knowledge, but missing out on the early stuff would lead to a similar effect.