My colleague, Amy Bruckman, wrote a blog post about the challenges that nonprofits face when trying to develop and maintain software. She concludes with an interesting argument for computing education that has nothing to do with learning programming that everyone needs. I think it relates to my question: What is the productivity cost of not understanding computing? (See post here.)
This is not a new phenomenon. Cliff Lampe found the same thing in a study of three nonprofits. At the root of the problem is two shortcomings in education. So that more small businesses and nonprofits don’t keep making this mistake, we need education about the software development process as part of the standard high-school curriculum. There is no part of the working world that is not touched by software, and people need to know how it is created and maintained. Even if they have no intention of becoming a developer, they need to know how to be an informed software customer. Second, for the people at web design firms who keep taking advantage of customers, there seems to be a lack of adequate professional ethics education. I teach students in my Computers, Society, and Professionalism class that software engineers have a special ethical responsibility because the client may not understand the problem domain and is relying on the knowledge and honesty of the developer. More people need to get that message.
Hilary Dwyer is starting an effort to create a special interest group at the American Educational Research Association (AERA) just for computer science education. Please do complete her poll — especially if you are an AERA member. We need 75 signatures on the poll to be able to create the SIG.
I’ve been looking forward to seeing this article appear in CACM for over a year. Last January and May, I heard Sally Fincher give two talks about computing education research (CER), where she started by describing (failed) efforts to teach reading over the last hundred years. She created a compelling analogy. What educators were doing when they simplified the learning of reading seem analogous to our efforts today to simplify the learning of programming — but those efforts to teach simplified reading led to significant harm to the students. What harm are we doing to students when we teach programming in these new ways? She is not calling for an end to these efforts. Rather, she’s calling for research to figure out what we’re doing and to investigate the effects. She agreed to write up her story for Viewpoints, which is published this month in CACM. Thanks, Sally!
Other approaches believe it is more appropriate to use real syntax, but constrain the environment to a particular (attractive) problem domain so learners become fluent in a constrained space. Event-driven environments (such as Greenfoot) or scaffolded systems (like Processing.js) aim for the learner to develop an accurate mental model of what their code is doing, and ultimately transfer that to other environments. Although whether they actually do so remains unclear: we may be restricting things in the wrong way.
Still others hold that coding—howsoever approached—is insufficient for literacy and advocate a wider approach, taking in “computational thinking,” for instance as embedded in the framework of the “CS Principles”: Enduring Understandings, Learning Objectives, and Essential Knowledge.
What is resolutely held common with traditionally formulated literacy is that these approaches are unleashed on classrooms, often whole school districts, even into the curriculum of entire countries—with scant research or evaluation. And without carrying the teachers. If we are to teach computing in schools we should go properly equipped. Alongside the admirable energy being poured into creating curricular and associated classroom materials, we need an accompanying set of considered and detailed programs of research, to parallel those done for previous literacies.
The ICER 2015 Doctoral Consortium provides an opportunity for doctoral students studying computing education to explore and develop their research interests in a workshop environment with a panel of established researchers. We invite students to apply for this opportunity to share their work with students in a similar situation as well as senior researchers in the field.
Applicants to the Doctoral Consortium should have begun their research, but should not have completed it in its entirety. We want people who have questions to raise with their peers and the more senior mentors. Someone who is all-but-defended probably does not want to be raising any questions.
DC Co-Chairs for 2015:
Mark Guzdial, Georgia Institute of Technology
Anthony Robins, University of Otago, New Zealand
Contact us at: firstname.lastname@example.org
The DC has the following objectives:
- Provide a supportive setting for feedback on students’ research and research direction
- Offer each student comments and fresh perspectives on their work from researchers and students outside their own institution
- Promote the development of a supportive community of scholars
- Support a new generation of researchers with information and advice on research and academic career paths
- Contribute to the conference goals through interaction with other researchers and conference events
The DC will be held on Sunday, August 9 2015. Students at any stage of their doctoral studies are welcome to apply and attend. The number of participants is limited to 15. Applicants who are selected will receive a limited partial reimbursement of travel, accommodation and subsistence (i.e., food) expenses of $600 (USD).
- Wednesday 20th May – initial submission
- Monday 1st June – notification of acceptance
- Monday 15th June – camera ready copy due
You can find more information on applying at http://icer.hosting.acm.org/icer-2015/doctoral-consortium/
End the ‘leaky pipeline’ metaphor when discussing women in science: Technical knowledge can be used in many domains
I’m familiar with the argument that we shouldn’t speak of a “pipeline” because students come to STEM (and computing, specifically) in lots of ways, and go from computing into lots of disciplines. The below-linked essay makes a particular point that I find compelling. By using the “leaky pipeline” metaphor, we stigmatize and discount the achievements of people (women, in particular in this article) who take their technical knowledge and apply it in non-computing domains. Sure, we want more women in computing, but we ought not to blame the women who leave for the low numbers.
However, new research of which I am the coauthor shows this pervasive leaky pipeline metaphor is wrong for nearly all postsecondary pathways in science and engineering. It also devalues students who want to use their technical training to make important societal contributions elsewhere.
How could the metaphor be so wrong? Wouldn’t factors such as cultural beliefs and gender bias cause women to leave science at higher rates?
My research, published last month in Frontiers in Psychology, shows this metaphor was at least partially accurate in the past. The bachelor’s-to-Ph.D. pipeline in science and engineering leaked more women than men among college graduates in the 1970’s and 80’s, but not recently.
Men still outnumber women among Ph.D. earners in fields like physical science and engineering. However, this representation gap stems from college major choices, not persistence after college.
Other research finds remaining persistence gaps after the Ph.D. in life science, but surprisingly not in physical science or engineering — fields in which women are more underrepresented. Persistence gaps in college are also exaggerated.
Cool example of using JES to access external data!
I’ve been teaching CCT 374: Technologies for Knowledge Media course this term. It seemed a natural fit to use a Media Computation approach to teach Python programming. The students have a term project where they had to design an application that uses City of Toronto Open Data. Just about every team decided to make something that involved displaying something on a map. So, I had to figure out how to display arbitrary maps programmatically, as simply as possible. Using the Google Maps API would have been beyond most of the students. Then I found a blog post with a Python program to retrieve static images from Google Maps.
I have adapted the code from the blog post to work within JES (Java Environment for Students) using the Media Computation libraries. I’ve made the code available on a gist.
These do sound like the kinds of things that learning scientists were saying at the start of the MOOC hype (like this post), but I’m glad that he now realizes that MOOCs have limited use and that students vary widely.
And as for MOOCs, which many still predict will displace traditional teaching, he said that they “were the answer when we weren’t sure what the question was.”
He said that their massive nature, which attracted so much attention, was ultimately a problem. “When I think about MOOCs, the advantage — the ability to prepare a course and offer it without personal interaction — is what makes them inexpensive and makes them very limited.”
Students “vary widely in terms of their skills and capability,” he said, such that massiveness is simply not an educational advantage. “For some it’s too deep and for some it is too shallow.”