The SIGCSE-members list recently had a discussion about whether students are born with programming ability (the so-called "Geek Gene"), or if effort leads to greater programming ability. As one correspondent put it:
Over the years, I have come to believe that those of us who can become successful programmers have different internal wiring than most in the population.
This is one form of the "Geek Gene" hypothesis — that students are either born with the ability to program, or they’re not. Teaching doesn’t have much to do with it. Raymond Lister has a thought a lot about the "Geek Gene" hypothesis as described in an Inroads article, presented at ICER 2013, and studied in his award-winning paper (with co-authors Porter and Zingaro). In general, Raymond doesn’t see a reason to believe in the "Geek Gene."
The "Geek Gene" hypothesis is widely held among computer science faculty. Clayton Lewis found in a survey in 2007 (see article here) that CS faculty who responded strongly disagree (77%) with the sentence: "Nearly everyone is capable of succeeding in the computer science curriculum if they work at it." The CS students surveyed were far more likely to agree with the statement than the CS faculty!
In educational psychology terms, those that hold to the "Geek Gene" hypothesis have a fixed mindset, as opposed to a growth mindset. These are terms used by Carol Dweck to describe how students approach their studies. (See her webpage here, and a relevant Wikipedia article here.) Students with a fixed mindset believe that their abilities are fixed from birth. It’s a talent that either you got or you don’t. If fixed mindset students do badly on a test, they chalk it up to fate. "Guess I’m just not good at that — have to find a new field that I’m good at." A growth mindset student believes that dedication and hard work can lead to greater success. A bad grade leads to the reaction, "I have to work harder next time." There is significant evidence that a growth mindset leads to greater effort and achievement.
Fortunately, there are studies that show that we can teach a growth mindset. We can help students change from a fixed to a growth mindset. In fact, Quintin Cutts and his colleagues showed a successful intervention that improved computing students’ performance by encouraging a growth mindset (paper here). But that kind of intervention is not possible if the teachers themselves have the fixed mindset.
The most dangerous part of the "Geek Gene" hypothesis is that it gives us a reason to stop working at broadening participation in computing. If people are wired to program, then those who are programming have that wiring, and those who don’t program must not have that wiring. Belief in the "Geek Gene" makes it easy to ignore female students and those from under-represented minority groups as simply having the wrong genes. The problem is that those who seem like they have a "Geek Gene" or who are well-prepared are typically the students who have had privileges, who have had the opportunity to develop ability in computing before they enter our classroom. We need to teach as if anyone can learn to program in order to broaden participation in computing and develop a more diverse computing community and workforce.
The notion that we can develop expertise through dedication and deliberate practice is at the core of the growth mindset. A recent Slate article (available here) argued, "Practice doesn’t make perfect." The Slate authors claim that practice doesn’t explain enough of the variance in expertise, so they conclude that it is likely genetic/innate differences that explain expertise. I’ve just written a blog post (see here) explaining why the claims of the Slate article and the meta-analysis behind it are mistaken. Nobody says that just practice leads to expertise. Challenging practice and practice with a teacher is far more effective than just practice. What we’re calling genetic or innate differences is far more likely to be due to experiences before the classroom. If you believe that writing out the instructions to making a peanut butter and jelly sandwich (as in this exercise) can help develop computing expertise, why wouldn’t you believe that kids who (for example) write out more instructions for others or explain more things to others before coming into our classes might have a headstart on developing expertise?
From our perspective as teachers, it shouldn’t matter why a student is less-prepared than others in the class. We can help all students improve. Deliberate practice leads to expertise, and deliberate practice is facilitated by good teaching.
The belief that students are born or have "different internal wiring" to be a programmer ignores the value of the teacher. A 2012 OECD report put the point in two words: "Teachers Matter." Hours of practice with a good teacher are far more likely to contribute to expertise than hours of practice alone. Rather than worry about our students’ genetics, we should be thinking about how to make ourselves more effective as teachers.
Teaching is not an innate skill. I guarantee that I can help novices learn programming far better hour-for-hour than if the novices worked on their own or via a self-study service like Khan Academy or Code Academy. I don’t have special teaching genes. I am comfortable making that claim because I have worked hard at learning what computing students typically get wrong, how to diagnose the problems, and how to orchestrate learning situations where they develop more robust understanding. We can learn to be better teachers.
Just how much can good teaching overcome genetic/innate differences or differences due to prior background? Here’s a research question that is far more important than if P==NP. Is Teaching > Genetics? Even if programming has genetic/innate roots, how can we teach to get beyond those? Even if students have prior backgrounds that make them less prepared for our classes, how can we teach to bring them up to speed?
We can develop teaching strategies that get past problems rooted in genetics. There are probably limits where good teaching can’t help, but we don’t know those limits yet. We have some wonderful success stories:
Programming is certainly a malleable cognitive skill, like spatial reasoning and subitizing. So, even if you believe that programming is a "wired" ability, or if you get groups of students in your classes who aren’t prepared, there’s every reason to believe that you can still teach them to program better than they could when they enter your class.
The critical issue is that we in computing education need to take seriously the development of teaching techniques, the research on the most effective teaching techniques, and the sharing of those findings. We can help students overcome difficulties or lack of preparation. We can help students develop growth mindsets. We can improve the programming expertise of any student who comes into our classes.
I think that your claim: "The most dangerous part of the "Geek Gene" hypothesis is that it gives us a reason to stop working at broadening participation in computing" is mistaken. To the contrary, even if there is a Geek Gene, it may be not be expressed if the student is discouraged from making a serious effort to learn (e.g. a female student intimidated by male students' behavior in a lab). Broading participation becomes critical because you don't want students with the Geek Gene not to have the chance to succeed.
Of course you're correct that good teaching "can improve the programming expertise of _any_ student", but I doubt that they "any" student will achieve a high level of competency.
Excellent article, Mark.
Has anybody seen articles that examine how quickly students with little or no prior experience learn how to program?
I see your point -- you're saying that, even if there is a Geek Gene, we should be encouraging all students so that they have the opportunity to discover if they have it. Of course, I agree with encouraging all students. My concern is that those who believe in the Geek Gene hypothesis will have fallible detectors, i.e., they may decide that a particular student "doesn't have it" and discourage the student to continue in computing. Since the Geek Gene doesn't actually exist, it's relatively arbitrary whether a teacher who believes in it might decide that a student "has it" or "doesn't." In general, it is risky to make educational decisions on an imagined characteristic.
It's an open question what level of competence any given student might achieve in programming. What's exciting to me is that it's really a design question. How do we design educational opportunities so that any student can reach as high a level of competence as possible?
There is research literature that explores different aspects of that question. For example, Deborah Fields and Yasmin Kafai are publishing a paper at WIPCSE this year where they studied all users at the Scratch website for a several month period, and described their exploration and programming behavior. One of their surprising findings is that those who programmed on the Scratch website are even less diverse than in our face-to-face CS classes. They suggest that we will need to use formal education to reach a more diverse audience with little or no prior experience, because those students are not using informal education opportunities to a significant extent.
I've commented to Mark on this in a different forum, but last week I saw an interesting article in the local Sunday newspaper that prompted me to do a bit more digging. The article was entitled "Practice isn't Perfect - Many Other Factors Affect Genius" by David Hambrick of Michigan State U, Fernanda Ferreira of the University of South Carolina and John Henderson, also of U of South Carolina. The article gives a good overview of what they term "one of psychology's oldest debates." According to the article, recent research tends to support the view that neither extreme (nature or nurture, if you will) is adequate alone to produce high levels of skill - both play a part, along with such factors as when they begin to study the subject in question, the quality of teaching, and various other factors, some clearly not well understood. The research doesn't explicitly refer to programming skill, but in every area of skill measured by the research there is a definite but limited extent to which any identifiable factor contributes to ultimate skill level. For example, the degree to which "practice" contributes to ultimate skill ranges from the low teens to the upper twenties, as a percent of the total.
As I see it, this supports the argument that we can and should find ways to teach more effectively and should not assume that some people lack the ability to learn, but also supports the argument that with some people there is only so much one can expect to achieve.
Another concern I have is the assumption that high levels of programming skill are required for success in the computing field. In over 40 years of working in industry, I found that a reasonable degree of programming skill is important for many entry level positions but there are many other skills that contribute to career success. I'd argue that the most important of these are ability to communicate effectively, good organizational skills and leadership skills. A mediocre programmer with excellent grades in reading and writing may be more successful in the long run than a hot shot programmer with mediocre grades in reading and writing.
Dennis, that's the Slate article that I mention above (at http://www.slate.com/articles/health_and_science/science/2014/09/malcolm_gladwell_s_10_000_hour_rule_for_deliberate_practice_is_wrong_genes.single.html). This blog post is the second of a series that I wrote, and the first is the post where I explain how the Slate authors got it wrong. They don't distinguish between practice, deliberate practice, and teacher-guided practice. Further, just because they can't explain variance in expertise through practice hours, does not mean that the only other explanation is genetics. You can find that post here: http://computinged.wordpress.com/2014/10/13/the-10k-rule-stands-deliberate-practice-leads-to-expertise-and-teaching-can-trump-genetics/
Displaying all 5 comments