Posts tagged ‘computing education’
The article below is from the Berkeley student newspaper, but it’s not just a Berkeley issue. Enrollment is surging, and schools have too few resources to meet demand. Dealing with the enrollment surge was a big topic at the ACM Education Council last month. Based on what I heard at last year’s meeting of the Ed Council, I predicted that the enrollment surge would like lead to less diversity in CS (see blog post here). This year, I came away with the sense that most attendees believe it’s quite likely. The issue now is measuring the impact and seeing what resources can be marshaled once there’s evidence that there has been damage to diversity. Both CRA and the National Academies are conducting studies about the impact of the enrollment surge. Right now, action is more about studying the impact than responding to the need — people might be willing to respond, but we have so few options. Google has funded several projects to invent new ways to respond (see blog post here), but those are just starting now. We won’t know for months if they’ll work.
When the culture at UC Berkeley simultaneously stresses the importance of a computer science education and heightens GPA requirements for the major, barriers to entry become increasingly difficult to overcome. More and more students entering UC Berkeley feel pressured to learn basic computer science skills to meet the needs of the postgraduation job market — a notion that the campus and its highly ranked computer science department encourage…But the upsurge in enrollment means fewer resources for beginner students, especially in terms of access to teaching assistants and professors.
The computer science department recently changed its requirements for petitioning for admission to the major: Students who entered UC Berkeley before this fall needed a cumulative GPA of 3.0 in the seven lower-division course requirements, whereas students who came in this fall need to complete, specifically, CS 61A, 61B and 70 with a cumulative GPA of 3.3. These are arguably the more difficult “weeder courses” within the prerequisites, and increasing the average required GPA from a B to a B+ makes a real difference for many deserving students hoping to earn a computer science degree. In CS 61A, for example, the past average is a 2.84, or a B-. Holding beginners to such a high standard, especially given the amount of pressure from an increasingly technologically focused society, is a tool to sort students into winners and losers rather than educate them.
The story in the blog post connects to my previous blog post about CS faculty arguing against doing something other than lectures in their classes. Here the authority figures are preventing the rest from considering evidence. What a weird place for a scientific meeting to be at, but we really do listen to authority more than evidence.
On the scientific side, the meeting brought together a number of thought leaders detailing how different components of the scientific community perform. For instance, we learned that peer-review is quite capable of weeding out obviously weak research proposals, but in establishing a ranking order among the non-flawed proposals, it is rarely better than chance. We learned that gender and institution biases are rampant in reviewers and that many rankings are devoid of any empirical basis. …The emerging picture was clear: we have quite a good empirical grasp of which approaches are and in particular which are not working. Importantly, as a community we have plenty of reasonable and realistic ideas of how to remedy the non-working components. However, whenever a particular piece of evidence was presented, one of the science leaders got up and proclaimed “In my experience, this does not happen” or “I cannot see this bias”, or “I have overseen a good 600 grant reviews in my career and these reviews worked just fine”. Looking back, an all too common scheme of this meeting for me was one of scientists presenting data and evidence, only to be countered by a prominent ex-scientist with a “I disagree without evidence”. It appeared quite obvious that we do not seem to suffer from a lack of insight, but rather from a lack of implementation.
In my research, I’m most interested in the non-CS majors, the ones who learn computing because it makes them more productive (see where I make that argument) or because they want to make themselves more marketable (see Eric Robert’s post) or because they will live and work (as I predict) in the fat line between programmers and users (see post here). A recent article in the CACM suggests that all non-CS majors need to be learn (let’s not use the “be exposed” euphemism — there’s no sense in “exposing” someone to something unless you’d like them to learn from it) “functional programming languages [and] the declarative programming paradigm.” I’m willing to consider that, but why? The quote below says, “they allow programmers to do more with less and enable compilation to more efficient code across a wide range of runtime targets.” I’ve been studying non-CS majors who program for a lot of years, and I’ve never heard any of them say even once that they want to “enable compilation to more efficient code across a wide range of runtime targets.”
So let’s consider the “more with less.” Do we buy that what what non-CS majors is to be able to get more expressive power with fewer keystrokes? I don’t see the argument for that.
- Brian Dorn studied graphic designers who program, and found that assignment was fairly hard for them to learn (see his CHI 2010 paper). Surely, there’s not much that has fewer characters than that.
- Neil Brown has been mining the BlueJ Blackbox data for empirical data on what students get wrong most often (see his ICER paper). I was surprised to learn that confusing & for && and | for || is pretty common. Those are pretty easy to type, short, and seemingly error-prone expressions.
- We have Thomas Green’s fascinating result that that IF P THEN … END P; IF NOT P THEN … END NOT P. is not just better than IF P THEN…ELSE.… It’s ten times better — novices do better by a magnitude if they avoid ELSE.
My suspicion is that non-CS major programmers value understandability and fewer errors, over fewer keystrokes and more power.
I like functional programming and would be interested in a good argument for it for non-CS majors. I don’t see it here.
Second, would-be programmers (CS majors or non-majors) should be exposed as early as possible to functional programming languages to gain experience in the declarative programming paradigm. The value of functional/declarative language abstractions is clear: they allow programmers to do more with less and enable compilation to more efficient code across a wide range of runtime targets. We have seen such abstractions gain prominence in DSLs, as well as in imperative languages such as C#, Java, and Scala, not to mention modern functional languages such as F# and Haskell.
I was honored to serve on Michael Lee’s dissertation committee. Mike’s basic thesis is available at this link, or you can get the jumbo-expanded edition with an enormous appendix describing everything in his software plus his learning evaluation (described below) at this link. His thesis brings together several studies he’s done on Gidget, his game in which he teaches programming. I’ve written about his work before, like his terrific finding that including assessments improves engagement in his game (see blog post here) and about how Gidget offers us a new way to think about assessing learning (see blog post here).
Michael had several fascinating results with Gidget. One of my favorites that I have not blogged on yet was that personifying the programming tool improves retention (see his ICER 2011 paper here). When Gidget sees a syntax error, she (I’m assigning gender here) doesn’t say, “Missing semicolon” or “Malformed expression.” Instead, she says “I don’t what this is, so I’ll just go on to the next step” and looks sad that she was unable to do what the programmer asked her to do. The personification of the programming tool dramatically improved the number of game levels completed. They kept going. In course terms, they were retained.
The dissertation has yet another Big Wow result. Mike developed an assessment of computing knowledge based on Allison Elliott Tew’s work on FCS1 (see here). He did a nice job validating it using Amazon’s Mechanical Turk.
He then compares three different conditions for learning differences:
- Gidget, as a game for learning.
- CodeAcademy, as a tutorial for learning.
- The Gidget game level designer. The idea was to provide a constructionist learning environment without a curriculum. Mike wanted it be like using Scratch or Alice or any other open-ended creative programming environment. What would the students learn without guidance in Gidget?
Gidget and CodeAcademy are statistically equivalent for learning, and both blow away the constructionist option. A designed curriculum beats a discovery-based learning opportunity. That’s interesting but not too surprising. Here’s the wild part: The Gidget users spend 1/2 as much time. Same learning, half as much time. I would not have predicted this, that Mike’s game is actually more efficient for learning about CS than is a tutorial. I’ve argued that learning efficiency is super important especially for high school teachers (see post here).
Mike is now an assistant professor at the New Jersey Institute of Technology (see his web page here). I wish him luck and look forward to what he does next!
The world is about more than computing. It’s easy for those of us who live and work in CS to see it as CS-centric. I work in a section of Atlanta that is bursting with high-tech startups. I found this article compelling — not because it threw cold water on the vision of Atlanta as a “Silicon Valley East,” but because it painted a picture of how much more diverse the economy in Atlanta really is.
In reality, metro Atlanta’s relationship with the tech sector is, well, complicated.
Georgia boasts about 280,000 tech jobs, according to Technology Association of Georgia president and chief executive officer Tino Mantella — the great majority of them in metro Atlanta. But information technology jobs only make up about 3.5 percent of the area’s labor market, down from a peak of 4.7 percent in the 1990s, federal Bureau of Labor data shows.
And California, home to the real Silicon Valley, dominates venture capital investing — the lifeblood of tech startups — with 56 percent of spending compared to the 1 percent in Georgia, Mantella said.
I believe the result described in the article below, that a critical limitation of teacher’s ability to use technology is too little understanding of technology. In a sense, this is another example of the productivity costs of a lack of ubiquitous computing literacy (see my call for a study of the productivity costs). We spend a lot on technology in schools. If teachers learned more about computing, they could use it more effectively.
In 2010, for example, researchers Peggy A. Ertmer of Purdue University, in West Lafayette, Ind., and Anne T. Ottenbreit-Leftwich of Indiana University, in Bloomington, took a comprehensive look at how teachers’ knowledge, confidence, and belief systems interact with school culture to shape the ways in which teachers integrate technology into their classrooms.
One big issue: Many teachers lack an understanding of how educational technology works.
But the greater challenge, the researchers wrote, is in expanding teachers’ knowledge of new instructional practices that will allow them to select and use the right technology, in the right way, with the right students, for the right purpose.
I predict that if we did this study with CS teachers, we’d find the same result. The belief that CS is for males and not for females is deeply ingrained in the perceptions of our field. Kahneman would tell us that it’s part of our System 1 thinking (see NYTimes Book Review). What do you think teachers would draw if asked to “draw a computer scientist“? I predict that the gender bias that favors males as computer scientists would be greater for post-secondary teachers than for secondary or elementary teachers. Most secondary school CS teachers that I’ve met are sensitive to issues of gender diversity in computing, and they actively encourage their female students. Most post-secondary CS teachers with whom I’ve worked are not sensitized to issues of women in computing and have not changed how they teach to improve gender diversity (see example here).
In the study, teachers graded the math tests of 11-year-olds and, on average, the scores were lower for girls. But, when different teachers graded the same tests anonymously, the girls performed far better (out-performing the boys in many cases.)
Dr. Edith Sand, one of the researchers, told American Friends of Tel Aviv University, that the issue wasn’t overt and obvious sexism, but “unconscious discouragement.”
The study goes on to say that the gender biases held by elementary school teachers have an “asymmetric effect” on their students — the boys’ performance benefits and girls’ performance suffers based on the teacher’s biases. Boys do well because teachers believe they will, girls don’t because teachers believe they won’t.