Posts tagged ‘computing for all’
US National Science Foundation increases emphasis on broadening participation in computing
The computing directorate at the US National Science Foundation (CISE) has increased its emphasis on broadening participation in computing (BPC). (See quote below and FAQ here.) They had a pilot program where large research grants were required to include a plan to increase the participation of groups or populations underrepresented or under-served in computing. They are now expanding the program to include medium and large scale grants. The idea is to get more computing researchers nationwide focusing on BPC goals.
CISE recognizes that BPC requires an array of long-term, sustained efforts, and will require the participation of the entire community. Efforts to broaden participation must be action-oriented and must take advantage of multiple approaches to eliminate or overcome barriers. BPC depends on many factors, and involves changing culture throughout academia—within departments, classrooms, and research groups. This change begins with enhanced awareness of barriers to participation as well as remedies throughout the CISE community, including among principal investigators (PIs), students, and reviewers. BPC may therefore involve a wide range of activities, examples of which include participating in professional development opportunities aimed at providing more inclusive environments, joining various existing and future collective impact programs to helping develop and implement departmental BPC plans that build awareness, inclusion, and engagement, and conducting outreach to underrepresented groups at all levels (K-12, undergraduate, graduate, and postgraduate).
In 2017, CISE commenced a pilot effort to increase the community’s involvement in BPC, by requiring BPC plans to be included in proposals for certain large awards [notably proposals to the Expeditions in Computing program, plus Frontier proposals to the Cyber-Physical Systems and Secure and Trustworthy Cyberspace (SaTC) programs]. By expanding the pilot to require that Medium and Large projects in certain CISE programs [the core programs of the CISE Divisions of Computing and Communication Foundations (CCF), Computer and Network Systems (CNS), and Information and Intelligent Systems (IIS), plus the SaTC program] have approved plans in place at award time in 2019, CISE hopes to accomplish several things:
- Continue to signal the importance of and commitment to BPC;
- Stimulate the CISE community to take action; and
- Educate the CISE community about the many ways in which members of the community can contribute to BPC.
The long-term goal of this pilot is for all segments of the population to have clear paths and opportunities to contribute to computing and closely related disciplines.
Read more at https://www.nsf.gov/pubs/2018/nsf18101/nsf18101.jsp
Are you talking to me? Interaction between teachers and researchers around evidence, truth, theory, and decision-making
In this blog, I’m talking about computing education research, but I’m not always sure and certainly not always clear about who I’m talking to. That’s a problem, but it’s not just my problem. It’s a general problem of research, and a particular problem of education research. What should we say when we’re talking to researchers, and what should we say when we’re talking to teachers, and where do we need to insert caveats or explain assumptions that may not be obvious to each audience?
From what I know of philosophy of science, I’m a post-positivist. I believe that there is an objective reality, and the best tools that we humans have to understand it are empirical evidence and the scientific method. Observations and experiments have errors and flaws, and our perspectives are biased. All theory should be questioned and may be revised. But that’s not how everyone sees the world, and what I might say in my blog may be perceived as a statement of truth, when the strongest statement I might make is a statement of evidence-supported theory.
It’s hard to bridge the gap between researchers and education. Lauren Margulieux shared on Twitter a recent Educational Researcher article that addresses the issue. It’s not about getting teachers access to journal articles, because those articles aren’t written to speak to nor address teachers’ concerns. There have to be efforts from both directions, to help teachers to grok researchers and researchers to speak to teachers.
I have three examples to concretize the problem.
Recursion and Iteration
I wrote a blog post earlier this month where I stated that iteration should be taught before recursion if one is trying to teach both. For me, this is a well-supported statement of theory. I have written about the work by Anderson and Wiedenbeck supporting this argument. I have also written about the terrific work by Pirolli exploring different ways to teach recursion, which fed into the work by Anderson.
In the discussion on the earlier post, Shriram correctly pointed out that there are more modern ways to teach recursion, which might make it better to teach before iteration. Other respondents to that post point out the newer forms of iteration which are much simpler. Anderson and Wiedenbeck’s work was in the 1980’s. That sounds great — I would hope that we can do better than what we did 30 years ago. I do not know of studies that show that the new ways work better or differently than the ways of the 1980’s, and I would love to see them.
By default, I do not assume that more modern ways are necessarily better. Lots of scientists do explore new directions that turn out to be cul-de-sacs in light of later evidence (e.g., there was a lot of research in learning styles before the weight of evidence suggested that they didn’t exist). I certainly hope and believe that we are coming up with better ways to teach and better theories to explain what’s going on. I have every reason to expect that the modern ways of teaching recursion are better, and that the FOR EACH loop in Python and Java works differently than the iteration forms that Anderson and Wiedenbeck studied.
The problem for me is how to talk about it. I wrote that earlier blog post thinking about teachers. If I’m talking to teachers, should I put in all these caveats and talk about the possibilities that haven’t yet been tested with evidence? Teachers aren’t researchers. In order to do their jobs, they don’t need to know the research methods and the probabilistic state of the evidence base. They want to know the best practices as supported by the evidence and theory. The best evidence-based recommendation I know is to teach iteration before recursion.
But had I thought about the fact that other researchers would be reading the blog, I would have inserted some caveats. I mean to always be implicitly saying to the researchers, “I’m open to being proven wrong about this,” but maybe I need to be more explicit about making statements about falsifiability. Certainly, my statement would have been a bit less forceful about iteration before recursion if I’d thought about a broader audience.
Making Predictions before Live Coding
I’m not consistent about how much evidence I require before I make a recommendation. For a while now, I have been using predictions before live coding demonstrations in my classes. It’s based on some strong evidence from Eric Mazur that I wrote about in 2011 (see blog post here). I recommend the practice often in my keynotes (see the video of me talking about predictions at EPFL from March 2018).
I really don’t have strong evidence that this practice works in CS classes. It should be a pretty simple experiment to test the theory that predictions before seeing program execution demonstrations helps with learning.
- Have a set of programs that you want students to learn from.
- The control group sees the program, then sees the execution.
- The experimental group sees the program, writes down a prediction about what the execution will be, then sees the execution.
- Afterwards, ask both groups about the programs and their execution.
I don’t know that anybody has done this experiment. We know that predictions work well in physics education, but we know that lots of things from physics education do not work in CS education. (See Briana Morrison’s dissertation.)
Teachers have to do lots of things for which we have no evidence. We don’t have enough research in CS Ed to guide all of our teaching practice. Robert Glaser once defined education as “Psychology Engineering,” and like all engineers, teachers have to do things for which we don’t have enough science. We make our best guess and take action.
So, I’m recommending a practice for which I don’t have evidence in CS education. Sometimes when I give the talk on prediction, I point out that we don’t have evidence from CS. But not always. I probably should. Maybe it’s enough that we have good evidence from physics, and I don’t have to get into the subtle differences between PER and CER for teachers. Researchers should know that this is yet another example of a great question to be addressed. But there are too few Computing Education Researchers, and none that I know are bored and looking for new experiments to run.
Code.org and UTeach CSP
Another example of the complexity of talking to teachers about research is reflected in a series of blog posts (and other social media) that came out at the end of last year about the AP CS Principles results.
- UTeach wrote a blog post in September about the excellent results that their students had on the AP CSP exam (see post here). They pointed out that their pass rate (83%) was much higher than the national average of 74%, and that advantage in pass rates was still there when the data were disaggregated by gender or ethnicity.
- There followed a lot of discussion (in blog posts, on Facebook, and via email) about what those results said about the UTeach curriculum. Should schools adopt the UTeach CSP curriculum based on these results?
- Hadi Partovi of Code.org responded with a blog post in October (see post here). He argued that exam scores were not a good basis for making curriculum decisions. Code.org’s pass rates were lower than UTeach’s (see their blog post on their scores), and that could likely be explained by Code.org’s focus on under-represented and low-SES student groups who might not perform as well on the AP CSP for a variety of reasons.
- Michael Marder of UTeach responded with two blog posts. One conducted an analysis suggesting that UTeach’s teacher professional development, support, and curriculum explained their difference from the national average (see post here), i.e., it wasn’t due to what students were served by UTeach. A second post tried to respond to Hadi directly to show that UTeach did particularly well with underrepresented groups (see post here).
I don’t see that anybody’s wrong here. We should be concerned that teachers and other education decision-makers may misinterpret the research results to say more than they do.
- The first result from UTeach says “UTeach’s CSP is very good.” More colloquially, UTeach doesn’t suck. There is snake oil out there. There are teaching methods that don’t actually work well for anyone (e.g., we could talk some more about learning styles) or only work for the most privileged students (e.g., lectures without active learning supports). How do you show that your curriculum (and PD and support) is providing value, across students in different demographic groups? Comparing to the national average (and disaggregated averages) is a reasonable way to do it.
- There are no results saying that UTeach is better than Code.org for anyone, or vice-versa. I know of no studies comparing any of the CSP curricula. I know of no data that would allow us to make these comparisons. They’re hard to do in a way that’s convincing. You’d want to have a bunch of CSP students and randomly assign them to either UTeach and Code.org, trying to make sure that all relevant variables (like percent of women and underrepresented groups) is the same in each. There are likely not enough students taking CSP yet to be able to do these studies.
- Code.org likely did well for their underrepresented students, and so did UTeach. It’s impossible to tell which did better. Marder is arguing that UTeach did well with underrepresented groups, and UTeach’s success was due to their interventions, not due to the students who took the test. I believe that UTeach did well with underrepresented groups. Marder is using statistics on the existing data collected about their participants to make the argument about the intervention. He didn’t run any experiments. I don’t doubt his stats, but I’m not compelled either. In general, though, I’m not worried about that level of detail in the argument.
All of that said, teachers, principals, and school administrators have to make decisions. They’re engineers in the field. They don’t have enough science. They may use data like pass rates to make choices about which curricula to use. From my perspective, without a horse in the race or a dog in the fight, it’s not something I’m worried about. I’m much more concerned about the decision whether to offer CSP at all. I want schools to offer CS, and I want them to offer high-quality CS. Both UTeach and Code.org offer high-quality CS, so that choice isn’t really a problem. I worry about schools that choose to offer no CSP or no CS at all.
Researchers and teachers are solving different problems. There should be better communication. Researchers have to make explicit the things that teachers might be confused about, but they might not realize what the teachers are confused about. In computing education research and other interdisciplinary fields, researchers may have to explain to each other what assumptions they’re making, because their assumptions are different in different fields. Teachers may use research to make decisions because they have to make decisions. It’s better for them to use evidence than not to use evidence, but there’s a danger in using evidence to make invalid arguments — to say that the evidence implies more than it does.
I don’t have a solution to offer here. I can point out the problem and use my blog to explore the boundary.
Reflections of a CS Professor and an End-User Programmer
In my last blog post, I talked about the Parsons problems generator that I used to put scrambled code problems on my quiz, study guide, and final exam. I’ve been reflecting on the experience and what it suggests to me about end-user programming.
I’m a computing professor, and while I enjoy programming, I mostly code to build exercises and examples for my students. I almost never code research prototypes anymore. I only occasionally code scripts that help me with something, like cleaning data, analyzing data, or in this case, generating problems for my students. In this case, I’m a casual end-user programmer — I’m a non-professional programmer who is making code to help him with some aspect of his job. This is in contrast:
- To Philip Guo’s work on conversational programmers, who are people who learn programming in order to talk to programmers (see his post describing his papers on conversational programmers). I know how to talk to programmers, and I have been a professional programmer. Now, I have a different job, and sometimes programming is worthwhile in that job.
- To computational scientists and engineers, which is the audience for Software Carpentry. Computational scientists and engineers might write code occasionally to solve a problem, but more importantly, they write code as part of their research. I might write a script to handle an odd-job, but most of my research is not conducted with code.
Why did I spend the time writing a script to generate the problems in LaTeX? I was teaching a large class, over 200 students. Mistakes on quizzes and exams at that scale are expensive in terms of emails, complaints, and regrading. Scrambled code problems are tricky. It’s easy to randomly scramble code. It’s harder to keep track of the right ordering. I needed to be able to do this many times.
Was it worthwhile? I think it was. I had a couple Parsons problems on the quiz, maybe five on the study guide, and maybe three on the final exam. (Different numbers at different stages of development.) Each one got generated at least twice as I refined, improved, or fixed the problem. (One discovery: Don’t include comments. They can legally go anywhere, so it only makes grading harder.) The original code only took me about an hour to get working. The script got refined many times as I used it, but the initial investment was well worth it for making sure that the problem was right (e.g., I didn’t miss any lines, and indentation was preserved for Python code) and the solution was correct.
Would it be worthwhile for anyone else to write this script facing the same problems? That’s a lot harder question.
I realized that I brought a lot of knowledge to bear on this problem.
- I have been a professional programmer.
- I do not use LiveCode often, but I have used HyperTalk a lot, and the environment is forgiving with lots of help for casual programmers like me. LiveCode doesn’t offer much for data abstraction — basically, everything is a string. I have experience using the tool’s facility with items, words, lines, and fields to structure data.
- I know LaTeX and have used the exam class before. I know Python and the fact that I needed to preserve indentation.
Then I realized that it takes almost as much knowledge to use this generator. The few people who might want to use the Parsons problem generator that I posted would have to know about Parsons problems, want to use them, be using LaTeX for exams, and know how to use the output of the generator.
But I bet that all (or the majority?) of end-user programming experiences are like this. End-users are professionals in some domain. They know a lot of stuff. They’ll bring a lot of knowledge to their programming activity. The programs will require a lot of knowledge to write, to understand, and to use.
One of the potential implications is that this program (and maybe most end-user programs?) are probably not useful to many others. Much of what we teach in CS1 for CS majors, or maybe even in Software Carpentry, is not useful to the occasional, casual end-user programmer. Most of what we teach is for larger-scale programming. Do we need to teach end-user programmers about software engineering practices that make code more readable by others? Do we need to teach end-user programmers about tools for working in teams on software if they are not going to be working in teams to develop their small bits of code? Those are honest questions. Shriram Krishnamurthi would remind me that end-user programmers, even more than any other class of programmers, are more likely to make errors and less likely to be able to debug them, so teaching end-user programmers practices and tools to catch and fix errors is particularly important for them. That’s a strong argument. But I also know that, as an end-user programmer myself, I’m not willing to spend a lot of time that doesn’t directly contribute towards my end goal. Balancing the real needs of end-user programmers with their occasional, casual use of programming is an interesting challenge.
The bigger question that I’m wondering about is whether someone else, facing a similar problem, could learn to code with a small enough time investment to make it worthwhile. I did a lot of programming in HyperTalk when I was a graduate student. I have that investment to build on. How much of an investment would someone else have to make to be able to write this kind of script as easily?
Why LiveCode? Why not Python? Or Smalltalk? I was originally going to write this in Python. Why not? I was teaching Python, and the problems would all be in Python. It’d good exercise for me.
I realized that I didn’t want to deal with files or a command line. I wanted a graphical user interface. I wanted to paste some code in (not put it in a file), and get some text that I could copy (not find it in one or more files). I didn’t want to have to remember what function(s) to call. I wanted a big button. I simply don’t have the time to deal with the cognitive load of file names and function names. Copy-paste the sorted code, press the button, then copy-paste the scrambled code and copy-paste the solution. I could do that. Maybe I could build a GUI in Python, but every time I have used a GUI tool in Python, it was way more work than LiveCode.
I also know Smalltalk better than most. Here’s a bit of an embarrassing confession: I’ve never really learned to build GUIs in Smalltalk. I’ve built a couple of toy examples in Morphic for class. But a real user interface with text areas that really work? That’s still hard for me. I didn’t want to deal with learning something new. LiveCode is just so easy — select the tool, drag the UI object into place.
LiveCode was the obvious answer for me, but that’s because of who I am and the background that I already have. What could we teach future professionals/end-user programmers that (a) they would find worthwhile learning (not too hard, not too time-consuming) and (b) they could use casually when they needed it, like my Parsons problem generator? That is an interesting computing education research question.
How does a student determine “worthwhile” when deciding what programming to learn for future end-user programming? Let’s say that we decided to teach all STEM graduate students some programming so that they could use it in their future professional practice as end-user programmers. What would you teach them? How would they judge something “worthwhile” to learn for later?
We know some answers to this question. We know that students judge the authenticity of the language based on what they see themselves doing in the future and what the current practice is in that field (see Betsy DiSalvo’s findings on Glitch and our results on Media Computation).
But what if that’s not a good programming language? What if there’s a better one? What if the common practice in a field is ill-informed? I’m going to be that most people, faced with the general problem I was facing (wanting a GUI to do a text-processing task) would use JavaScript. LiveCode is way better than JavaScript for an occasional, casual GUI task — easier to learn, more stable, more coherent implementation, and better programming support for casual users. Yet, I predict most people would choose JavaScript because of the Principle of Social Proof.
I’ve been reading Robert Cialdini’s books on social psychology and influence, and he explains that social proof is how people make decisions when they’re uncertain (like how to choose a programming language when they don’t know much about programming) and there are others to copy.
First, we seem to assume that if a lot of people are doing the same thing, they must know something we don’t. Especially when we are uncertain, we are willing to place an enormous amount of trust in the collective knowledge of the crowd. Second, quite frequently the crowd is mistaken because they are not acting on the basis of any superior information but are reacting, themselves, to the principle of social proof.
Cialdini PhD, Robert B.. Influence (Collins Business Essentials) (Kindle Locations 2570-2573). HarperCollins. Kindle Edition.
How many people know both JavaScript and LiveCode well? And don’t consider computer scientists. You can’t convince someone by telling them that computer scientists say “X is better than Y.” People follow social proof from people whom they judge to be similar to them. It’s got to be someone in their field, someone who works like them.
It would be hard to teach the graduate students something other than what’s in common practice in their fields, even if it’s more inefficient to learn and harder to use than another choice.
Integrating CS into other fields, so that other fields don’t feel threatened: Interview with Jane Prey
I really enjoyed the interview in the last SIGCSE Bulletin with Jane Prey. Her reason for doing more to integrate CS into other disciplines, at the undergraduate level, is fascinating — one I hadn’t heard before.
Other fields are nervous because they think we’re taking so many students from them, and universities are nervous because they’re afraid of losing us to industry. I would hate to lose any other faculty position to add a CS professor. I really believe it’s important for computing professionals to be well-rounded, to be able to appreciate what they learned in history, biology, and anthropology classes. We need to do a better job of integrating more of a student’s educational experiences. For example, how do we do more work together with the education schools? We just aren’t there. We have to work cross-disciplines to develop a path forward, even though it’s really hard.
Some principals are getting interested in CS, but think pressure for CS is mostly coming from Tech companies
How do high school principals in small, medium and large districts view the Computer Science for All movement?
High school leaders in smaller districts are most enthusiastic about the trend, a new survey by the Education Week Research Center found. Overall, 30% of all principals say CS is not “on their radar,” and 32% say CS is an “occasional supplement or enrichment opportunity.” I found the two graphs above interesting. The majority of principals aren’t particularly excited by CS, and most principals think that it’s the Tech firms that are pushing CS onto schools, not parents.
Source: Principals Warm Up to Computer Science, Despite Obstacles
Computer science education is far bigger than maker education: A post in lieu of a talk #InfyXRoads
I was scheduled to speak this Thursday in the final plenary panel of the Infosys Foundations USA CrossRoads 2018 conference (see program here). My father passed away on May 10, and we just had the funeral Friday May 18, so I apologized and cancelled the trip. I had already thought about what I wanted to say, so here’s a blog post in lieu of a panel presentation.
The session is “Why Teach CS? Why Teach Making?” with Yasmin Kafai, Quincy Brown, and Colleen Lewis. The session was inspired in part by my blog post listing the reasons for teaching programming, and was framed in our preliminary discussions as a debate. Is there a difference between CS education and Maker education? Yasmin was tasked with making the argument that they are pretty much the same. I disagree with that position. Colleen was moderating, and Quincy was still keeping her cards close to her chest — I don’t know what position she’s going to take Thursday.
If our goal is to teach the basics of programming, sure, maker education (where we teach students to make physical devices with embedded computation, such as e-textiles, robotics, or Lego Mindstorms devices) and the kind of computing education that I see reflected in the K-12 CS Framework is pretty much the same. There’s some CS education in there. Students learn the basics of sequential execution, conditionals, and looping. But that’s not the same as computer science education.
If our goal is to change students attitudes towards technology, then sure, maker education may be even more effective than computing education for getting students to see the technology in their world. By making their own technology, students may increase their self-efficacy, and help them to feel that they can and should have control over the technology in their lives. But again, that’s not the same as teaching students computer science.
The big ideas of computer science are much bigger than maker education. Here are three examples.
The questions that Alan Turing was trying to answer when he invented the Turing Machine were “What is computable? What are the limits of mathematics? What is not computable? Is even human intelligence computable?” These are as meta as you can get. This is the heart of computer science, as the science of abstraction. These aren’t ideas students currently explore in maker education. Maybe they could, but certainly don’t require a maker context.
One of the most powerful ideas associated with Turing Machines is that any computer can simulate any other computer, including being many other computers with many processes. That’s the big idea that Alan Perlis was talking about in 1961 when he talked about computer science as the study of process. That’s one of the big ideas behind object-oriented programming as Alan Kay defined it. We don’t explore simulation in maker education, and it’s hard to imagine how we might.
Ada Lovelace was the world’s first computer programmer. More than that, she was the first to realize that computers were about programming anything. Quoting from her Wikipedia page:
Ada saw something that Babbage in some sense failed to see. In Babbage’s world his engines were bound by number…What Lovelace saw—what Ada Byron saw—was that number could represent entities other than quantity. So once you had a machine for manipulating numbers, if those numbers represented other things, letters, musical notes, then the machine could manipulate symbols of which number was one instance, according to rules. It is this fundamental transition from a machine which is a number cruncher to a machine for manipulating symbols according to rules that is the fundamental transition from calculation to computation—to general-purpose computation—and looking back from the present high ground of modern computing, if we are looking and sifting history for that transition, then that transition was made explicitly by Ada in that 1843 paper.
Maker education isn’t about general computation. It’s about computing associated with sensors and actuators. Computer science education is about computing everything, from numbers to letters to musical notes. Having to connect the computation to a device made by the student limits the space of what you might compute. Computer science is about representation and abstractions on representations. Everything can be defined in terms of bits. That’s a big idea. You can probably teach that concept in maker education, but it can be taught (and more easily) without tying it to maker education.
Most of us know Grace Hopper’s name today, but probably more for her iconic status and as the namesake for the Grace Hopper Conference than for what she actually did. Admiral Grace Hopper led the effort to create compiled programming languages, including (eventually) COBOL. There are so many big ideas in here, but let’s just take two.
- Automatic programming means that you have a program specified in one language (like COBOL or Java or Scratch) and you use that as input to a program that generates another language written in another language (used to be machine language, but JavaScript is probably more common today). A compiler is a program that inputs a program and generates another a program. That is a powerful, meta idea that students do not typically see in maker education. Could we teach about compilers in maker education? Maybe, but “making” is certainly not the easiest and most obvious way to talk about compilers — it’s another way computing education is bigger than maker education.
- COBOL was about making programming accessible by using words and concepts familiar to the end users. (It was also about designing a compiled language that would work on any underlying computer, which connects back to Turing’s machine.) Designing for others who are not you and have different expertise than you is one of the most fundamental ideas of human-computer interface design today. Do we get to that in maker education? That big idea occurs more often in non-maker contexts, e.g., making apps for others and using user-centered design to get there.
Bottomline: CS education is so much bigger than maker education. You can explore a lot of computer science using student-made devices as a context. Ben Shapiro has shown that he can have kids playing with powerful modern-day computing ideas from networking to machine learning, all using student-made devices. That’s serious CS education. But it’s not all of CS education, and you can do CS education apart from student-made devices. Maker and CS education are not one-to-one.
There is an equity component here. We often talk about Ada Lovelace and Grace Hopper when we talk about the women who were part of the creation of computer science. We do them a disservice if we only remember them as early members of a category “women in computing.” It’s important to recognize what they actually did, what they contributed to computer science — and we should teach that. What Lovelace and Hopper did mattered, and we demonstrate that it mattered by teaching it and explaining why it’s important. Ideas like data representation and compilers are not today taught in maker education, are not easily taught in maker education, and can certainly be taught without maker education.
The big ideas that Turing, Lovelace, and Hopper created and explored are not new. This shouldn’t be the realm of advanced CS any more. An important goal of computer science education should be to teach these foundational ideas of computer science. I don’t think we know how to get there yet, but that should be our goal. We should be teaching the computer science developed by the people we hold up as heroes, leaders, and role models.
We can teach a lot with maker education, but let’s make sure that we don’t miss out on what CS education is about. Maker education is a great idea. It’s a terrific context for learning some of CS. If we only focus on the intersection of maker and CS education, we might miss the other, far bigger ideas that are in computer science.
Scale or Fail: Making national CS education work in Switzerland
Alex Repenning has the CACM Viewpoints Education column this month where he sets out a bold challenge — scale CS education to a national scale, or fail at making CS education work for all.
K–12 computer science Education (CSed) is an international challenge with different countries engaging in diverse strategies to reach systemic impact by broadening participation among students, teachers and the general population. For instance, the CS4All initiative in the U.S. and the Computing at School movement in the U.K. have scaled up CSed remarkably. While large successes with these kinds of initiatives have resulted in significant impact, it remains unclear how early impact becomes truly systemic. The main challenge preventing K–12 CSed to advance from teachers who are technology enthusiasts to pragmatists is perhaps best characterized by Crossing the Chasm, a notion anchored in the diffusion of innovation literature. This chasm appears to exist for CSed. It suggests it is difficult to move beyond early adopters of a new idea, such as K–12 CSed, to the early majority. Switzerland, a highly affluent, but in terms of K–12 CSed somewhat conservative country, is radically shifting its strategy to cross this chasm by introducing mandatory pre-service teacher computer science education starting at the elementary school level.
Three fundamental CSed stages are characterized by permutations of self-selected/all and students/teachers combinations. It took approximately 20 years to transition through these stages. Each stage is described here from a more general CSed perspective as well as my personal perspective.
Source: Scale or Fail
Feeling disadvantaged in CS courses at University of XXX
Even at Berkeley, the home of the great course emphasizing CS teaching for everyone, The Beauty and Joy of Computing, there are students who don’t feel that they belong in CS. See the post quoted and linked below.
Of course, the story below is not about Berkeley. This is about the slow pace of change, and how difficult it is to get whole CS departments to buy into the vision of “CS for All.”
CS 61A was a completely different story.
Last fall, I had the opportunity to work as a lab assistant for Data 8: “Foundations of Data Science,” and I couldn’t help but notice the difference in atmosphere between the students in Data 8 and my own experience in CS 61A.
Data 8 is one of the alternative courses offered for UC Berkeley students who are new programmers. Data 8 and CS 10: “The Beauty and Joy of Computing” are offered to students who want to test the waters of programming before jumping into 61A.
Data 8 uses Python, just like 61A. But the concepts are taught more slowly so new programmers can really understand how to use these concepts properly in their code.
Source: Column | Feeling disadvantaged in CS courses at UC Berkeley
Ever so slowly, diversity in computing jobs is improving: It’ll be equitable in a century
A great but sobering blog post from Code.org. Yes, computing is becoming more diverse, but at a disappointingly slow rate. Is it possible to go faster? Or is this just the pace at which we can change a field?
According to the Bureau of Labor Statistics, yes, but very slowly. We’ve analyzed the Current Population Survey data from the past few years to see how many people are employed in computing occupations, and the percentage of women, Black/African American, and Hispanic/Latino employees.
What did we find? There are about 5 million people employed in computing occupations, 24% of whom are women, and 15% of whom are Black/African American or Hispanic/Latino.
Since 2014, the trends in representation, although small, have been moving in the right direction — all three groups showed a tiny increase in representation. However, changes would need to accelerate significantly to reach meaningful societal balance in our lifetimes. If the current pace of increases continue, it would take over a century* until we saw balanced representation in computing careers.
Source: Is diversity in computing jobs improving? – Code.org – Medium
What can the Uber Gender Pay Gap Study tell us about improving diversity in computing?
The gig economy offers the ultimate flexibility to set your own hours. That’s why economists thought it would help eliminate the gender pay gap. A new study, using data from over a million Uber drivers, finds the story isn’t so simple.
Source: What Can Uber Teach Us About the Gender Pay Gap? – Freakonomics
A fascinating Freakonomics podcast tells us about why women are paid less than men (by about 7%) on Uber. They ruled out discrimination, after looking at a variety of sources. They found that they could explain all of that 7% from three factors.
They found that even in a labor market where discrimination can be ruled out, women still earn 7 percent less than men — in this case, roughly 20 dollars an hour versus 21. The difference is due to three factors: time and location of driving; driver experience; and average speed.
The first factor is that women choose to be Uber drivers in different places and at different times than men. Men are far more often to be drivers at 3 am on Saturday morning. The second factor is particularly interesting to me. Men tend to stick around on Uber longer than women, so they learn how to work the system. The third factor is that men drive faster, so they get more rides per hour.
When someone from Uber was asked about how they might respond to these results, he focused on the second factor.
But for example, you could imagine that if we make our software easier to use and we can steepen up the learning curve, then if people learn more quickly on the system, then that portion of the gap could be resolved via some kind of intervention. But that’s just an example. And we’re not there yet with our depth of understanding, to just simply write off the gender gap as a preference.
Improving learning might help shrink the gender pay gap. Obviously, I’m connecting this to computing education here. What role could computing education play in reducing gaps between males and females in computing? We have reason to believe that our inability to teach programming well led to the gender gap in computing. Could we make things better if we could teach computing well?
Here are two thoughts exploring that question.
- We know (e.g., from Unlocking the Clubhouse) that men tend to sink more time into programming, which can give them a lead in undergraduate education (what Jane Margolis has called ‘preparatory privilege‘). What if we could teach programming more efficiently? Could we close that gap? If we had a science of teaching programming, we could improve efficiency so that a few hours of focused effort in the classroom might lead to more effective learning of tens of hours of figuring out how to compile under Debian Linux.
- When I first started thinking about the “phonics of computing education” and our ebooks, I was inspired by work from Caroline Simard that suggested that helping female mid-level managers keep up their technical skills could help them to progress in the tech industry. Female mid-level managers have less time to invest in technical learning, and at the mid-level, technical education still matters. If you have a project that needs a new toolset, you’ll more likely give it to the manager who knows that toolset. If we could teach female mid-level technical managers more effectively and efficiently, could they make it into the C-suite of tech companies?
Maybe better computing education could be an important part of improving diversity, along multiple paths.
What Universities Must Do to Prepare Computer Science Teachers: UTeach leads a multi-university group to grow computing education
Kimberly Hughes, Director of the UTeach Institute at The University of Texas at Austin has written a blog post about a multi-university effort to grow CS education. They have an interesting set of recommendations. I look forward to seeing the white paper that the blog post promises!
In-service teacher professional development has been key to the explosive growth of K–12 CS education offerings, but the role of universities in the preparation of computer science teachers is absolutely critical if we are going to address the current shortage of CS teachers at scale and with any kind of lasting impact. Yet there are precious few exemplars on which to model new programs. Partly this has been a chicken and egg problem. For example, the UTeach program at UT Austin has had an undergraduate pathway to CS certification for more than ten years. But with so little demand for CS teachers at secondary schools throughout the state, very few students were recruited and prepared. Now that the demand for CS teachers is increasing, UTeach Austin and other UTeach partner universities are ramping up and expanding their efforts.
Source: What Universities Must Do to Prepare Computer Science Teachers: Networked Improvement in Action
Governor of Rhode Island explains why we should teach programming to everyone
Gina Raimondo, the governor of Rhode Island, was on Freakonomics Radio a few weeks ago. Stephen Dubner challenged their plans to offer computing education at all grade levels in every district. She had a strong response. Dubner’s question is good. We still don’t have the empirical evidence for the value of teaching computing to everyone. We should do that research — not to figure out if Raimondo made the right bet, but to tune what we’re doing to make sure that we get the maximum benefit for the investment.
I recommend the whole interview.
DUBNER: So, I hear about this kind of thinking a lot, and I certainly understand the appeal and the resonance. But I do also wonder if there’s a proven upside of having everyone learn computer science or programming. It strikes me a little bit like the equivalent of having every student in America during the boom of the internal combustion engine learn to take apart a carburetor. And then I think, if you look at the history of economics and progress, that one of the main strengths of economic progress is the division of labor and specialization, rather than everybody chasing after the latest trends. So I’m curious what the evidence was that inspired that move of yours.
RAIMONDO: I think of it as access and exposure, and also just providing people with a basic level of essential skills. So, everyone has to take math. They may become a writer, they may become an actor, but they ought to have a certain basic level of math skills. First of all, because it’s an essential skill to function. And by the way, they might like math. I think digital skills are the same thing. No matter what job you have, you have to have some basic familiarity with computer skills and digital skills. And so it is as essential in this economy as any other skill that we teach. But also, we know — and there’s loads of data on this girls, people of color, and low-income folks are less likely to go into I.T. fields, which tend to be higher-paying. However, if they’re exposed to some computer training, they’re much more likely to go into the field and do well at it.
Source: How to Be a Modern Democrat — and Win – Freakonomics
ECEP 2018: Measuring and Making Progress on Broadening Participation in Computing
The 2018 Annual Meeting of the Expanding Computing Education Pathways (ECEP) Alliance was at Georgia Tech January 26-27. ECEP is an NSF-funded alliance to broaden participation in computing. We had about 90 participants, state leaders from 16 states and Puerto Rico. Attendees were from a range of positions, from state departments of education, state boards of education, STEM centers, non-profits, Governor’s offices, University professors, and CS teachers from elementary or high school. The focus at this meeting was to define what it means to broaden participation in computing (BPC) education for each state. The state teams worked at defining what data variables they needed in order to inform their BPC goals, and how they would know (by looking at those data) if they were making progress towards those goals. You can see the play-by-play with pictures via Twitter hashtag #ECEP2017.
I learned so much at this event. I’m still processing all of it, but here are some of the things that are standing out to me right now.
Caitlin Dooley from Georgia Department of Education gave a terrific talk about the challenges in Georgia. She made the argument that CS is the equity issue of our age. She said that the challenge of getting CS teachers into poorer (low-SES) and rural districts is that teachers are leaving when they have the skillsets. The challenge is to have good school leaders to retain teachers.
Anne DeMallie from Massachusetts gave a compelling talk about how they’re integrating CS across the curriculum, especially in elementary school. Massachusetts and New Jersey are two states that integrated their CS and Digital Literacy standards, trying to make it easier for schools to integrate CS education. I liked the framework she offered on how to think about integrating CS into other subjects: exist, enhance, and extend.

I was impressed by the states who are setting concrete, measurable goals. Alabama has set a goal of every high school student having access to CS education by 2022. South Carolina plans to provide access to CS education in every middle and high school in five years. Maryland has a detailed 15 year plan that gets every student access to high-quality CS education with certified high school teachers. (Seen below, presented by Megean Garvin.)
Kamau Bobb of Constellations gave our keynote (as a “fireside chat” with Debra Richardson). His talk was exciting and challenging. He pointed out that high school CS isn’t going to get kids into University. Pushing CS instead of math and science isn’t helping students get admission to higher education. Schools aren’t held accountable for CS — they’re being held accountable for math, science, and language arts learning. CS has to play a role in meeting student and school needs.
Kamau pointed out that “Segregation is an immutable truth.” One of the stories he told was to about textual literacy. During Reconstruction (starting 1865), leaders realized the critical need for all African-Americans to learn to read. The Georgia Literacy Project to address the dramatic literacy gap was just started in 2010 — 145 years later. How long will it take us to achieve equitable access to computing education?
Most of the time was spent in working meetings — state teams sitting down with data reports, developing plans for broadening participation in CS, and grounding the plans in what data they have and what trends they expect to see in those data. The challenges of gathering data on the ground are huge. I was sitting with one state where a CS teacher on the team pointed out that she had 85 students this year. The Department of Education person from that state did a search, and found that none of those students showed up in their database. Other states pointed out how hard it is to compare data across states. We use AP CS data for these kinds of comparisons, but in some states (like Arkansas), all AP exams are paid for by the state. That means that more kids are taking the exam, which means that the pass rates have a different context.
The amount of support for CS Education from each state varies dramatically. Many states have no one in the Department of Education who is informed about CS. Here in Georgia, we have one full-time CS coordinator, which is terrific. In Arkansas, they have nine full-time CS specialists to help teachers.
It was energizing to be with so many passionate leaders who are working to improve computing education in their state. It’s also amazing to see how much work there is to go to reach everyone with high-quality computing education.
This was the last ECEP meeting organized by this group of NSF Principal Investigators. Rick Adrion, Renee Fall, Barbara Ericson, and I are done when the existing ECEP grant runs out at the end of September. We’ve worked with a new team of PI’s to help them build a proposal for ECEP 2. The amazing Sarah Dunton, the manager of our state and territory alliance, will continue in ECEP 2. The PIs for ECEP 2 are Carol Fletcher, Anne Leftwich, Debra Richardson, Maureen Biggers, and Leigh Ann DeLyser. We’re hoping that they get funded and continue to help states make progress on implementing and broadening computing education.
How the Imagined “Rationality” of Engineering Is Hurting Diversity — and Engineering
Just a few weeks ago, Richard Thaler won the Nobel prize in Economics. Thaler is famous for showing that real human beings are not the wholly rational beings that Economic theory had previously assumed. It’s timely to consider where else we assume rationality, and where that rational assumption may lead us into flawed decisions and undesirable outcomes. The below article from Harvard Business Review considers how dangerous the Engineering “purity” argument is.
Just how common are the views on gender espoused in the memo that former Google engineer James Damore was recently fired for distributing on an internal company message board? The flap has women and men in tech — and elsewhere — wondering what their colleagues really think about diversity. Research we’ve conducted shows that while most people don’t share Damore’s views, male engineers are more likely to…
But our most interesting finding concerned engineering purity. “Merit is vastly more important than gender or race, and efforts to ‘balance’ gender and race diminish the overall quality of an organization by reducing collective merit of the personnel,” a male engineer commented in the survey. Note the undefended assumption that tapping the full talent pool of engineers rather than limiting hiring to a subgroup (white men) will decrease the quality of engineers hired. Damore’s memo echoes this view, decrying “hiring practices which can effectively lower the bar for ‘diversity’ candidates.”
Google and taxpayer money, Damore opines, “is spent to water only one side of the lawn.” Many male engineers in our survey agreed that women engineers are unfairly favored. “As regards gender bias, my workplace offers women more incentives and monetary support than it does to males,” commented one male engineer. Said another, women “will always be safe from a RIF [reduction in force]. As well as certain companies guaranteeing female engineers higher raises.”
Source: How the Imagined “Rationality” of Engineering Is Hurting Diversity — and Engineering
Why should we teach programming (Hint: It’s not to learn problem-solving)
This is a revision of the original post. Several readers pointed out on Twitter that my original post was insensitive. It read like an attack on Brenda, a woman of color, from a senior white guy (me). That was not my intent, and I apologize for that. I am grateful to Joseph P. Wilson who helped me understand how to avoid that impression. I can’t change the post that went out yesterday, but I will be more careful in future blog posts.
At the CS for All Consortium Celebration Tuesday, Brenda Wilkerson gave the closing keynote. The full livestream of the CS for All Summit is available here, and it includes Brenda’s talk. I’m a huge fan of Brenda, and she’s done fabulous work in Chicago. She is a leader in bringing CS to All.
I have not seen Brenda’s talk or any of the livestream. My experience of the Consortium Celebration was through reading the Twitter stream as I found time during the day. Brenda had one slide (which you can see in the tweet linked here) that I disagreed with, and because it’s an important point, I’m going to respond to it here.
It says, “Computer science builds the mental discipline for breaking down problems, and solving them.” There are few studies that test this claim as “computer science,” but there have been lots of studies looking for transfer from teaching programming to general problem-solving skills. Probably the first study investigating this claim is Roy Pea and Midian Kurland’s paper On the cognitive effects of learning computer programming. You can find this claim in a paper by Henry Walker to which I responded in this blog. You can see it in posts all over the Internet, from this blog post to this article from a teacher in England. There is a strong belief out there that learning computer science, and programming called out specifically, leads to new problem-solving and “a new way to think.”
There is simply not evidence in support of these claims. I talk about these in my book, I reference the Palumbo meta-review in this blog post, and NYTimes wrote about it this last spring. Like “learning styles” and “Latin teaches thinking,” this is a persistent myth that learning computing leads to problem-solving skills, and we have no support the claim.
I tweeted in response to Brenda’s slide, and several CS teachers asked me, “So why teach programming or computing at all?” That’s a great question! Here are some of my top reasons:
- To understand our world. The argument that Simon Peyton Jones made in England for their computer science curriculum is that Computer Science is a science like all the others. We teach Chemistry to students because they live in a world with chemical interactions. We teach Biology because they live in a world full of living things. We teach Physics because they live in a physical world. We should teach Computer Science because they live in a digital world.
- To study and understand processes. Alan Perlis (first ACM Turing Award laureate) argued in 1961 that everyone on every campus should learn to program. He said that computer science is the study of process, and many disciplines need people to know about process, from managers who work on logistics, to scientists who try to understand molecular or biological processes. Programming automates process, which creates opportunities to simulate, model, and test theories about processes at scale. Perlis was prescient in predicting computational science and engineering.
- To be able to ask questions about the influences on their lives. C.P. Snow also argued for everyone to learn computing in 1961, but with more foreboding. He correctly predicted that computers and computing algorithms were going to control important aspects of our lives. If we don’t know anything about computing, we don’t even know how to ask about those algorithms. It shouldn’t be magic. Even if you’re not building these algorithms, simply knowing about them gives you power. C.P. Snow argues that you need that power.
- To use an important new form of literacy. Alan Kay made the argument in the 1970’s that computing is a whole new medium. In fact, it’s human’s first meta-medium — it can be all other media, and it includes interactivity so that the medium can respond to the reader/user/viewer. Computing gives us a new way to express ideas, to communicate to others, and to explore ideas. Everyone should have access to this new medium.
- To have a new way to learn science and mathematics. Mathematics places a critical role in understanding our world, mostly in science. Our notation for mathematics has mostly been static equations. But code is different and gives us new insights. This is what Andy diSessa has been saying for many years. Bruce Sherin, Idit Harel, Yasmin Kafai, Uri Wilensky, and others have shown us how code gives us a powerful new way to learn science and mathematics. Bootstrap explicitly teaches mathematics with computing. Everyone who learns mathematics should also learn computing, explicitly with programming.
- As a job skill. The most common argument for teaching computer science in the United States is as a job skill. The original Code.org video argued that everyone should learn programming because we have a shortage of programmers. That’s just a terrible reason to make every school child learn to program. That’s what Larry Cuban was arguing this last summer. Tax payers should not be funding a Silicon Valley jobs program. Not everyone is going to become a software developer, and it doesn’t make any sense to train everyone for a job that only some will do. But, there’s some great evidence from Chris Scaffidi (that I learned about from Amy Ko’s terrific VL/HCC summary) showing that workers (not software developers) who program make higher wages than those comparable workers who do not. Learning to program gives students new skills that have value in the economy. It’s a social justice issue if we do not make this economic opportunity available to everyone.
- To use computers better. This one is a possibility, but we need research to support it. Everyone uses computers all the time these days. Does knowing how the computer works lead to more effective use of the computer? Are you less likely to make mistakes? Are you more resilient in bouncing back from errors? Can you solve computing problems (those that happen in applications or with hardware, even without programming) more easily? I bet the answer is yes, but I don’t know the research results that support that argument.
- As a medium in which to learn problem-solving. Finally, computer programming is an effective medium in which we can teach problem-solving. Just learning to program doesn’t teach problem-solving skills, but you can use programming if you want to teach problem-solving. Sharon Carver showed this many years ago. She wanted students to learn debugging skills, like being able to take a map and a set of instructions, then figure out where the instructions are wrong. She taught those debugging skills by having students debug Logo programs. Students successfully transferred those debugging skills to the map task. That’s super cool from a cognitive and learning sciences perspective. But her students didn’t learn much programming — she didn’t need much programming to teach that problem solving skill.But here’s the big caveat: They did not learn enough programming for any of the other reasons on this list! The evidence we have says that you can teach problem-solving with programming, but students won’t gain more than that particular skill. That is a disservice to students.
Certainly there are more reasons than these, and I’ve seen several in the response to this blog post, and some in the comments below.
This was just one slide in Brenda’s talk. Her overall point was much more broader and more significant. I strongly agree with Brenda’s key point: CS for All is a social justice issue. Learning computing is so important that it is unjust to keep it from some students. Currently, CS is disproportionately unavailable to poorer students, to females, and to minority ethnic groups. We need CS for All.












Recent Comments