Posts tagged ‘computing for everyone’
Interesting and relevant for this list. There’s a lot in the NSF big ideas document (see link here) about using technology for learning, but there’s also some on what we want students to know (including about computing technology), e.g., “the development and evaluation of innovative learning opportunities and educational pathways, grounded in an education-research-based understanding of the knowledge and skill demands needed by a 21st century data-capable workforce.”
The six “research” ideas are intended to stimulate cross-disciplinary activity and take on important societal challenges. Exploring the human-technology frontier, for example, reflects NSF’s desire “to weave in technology throughout the fabric of society, and study how technology affects learning,” says Joan Ferrini-Mundy, who runs NSF’s education directorate. She thinks it will also require universities to change how they educate the next generation of scientists and engineers.
I’ve talked about Kamau Bobb’s work in this blog previously, when he wrote a depressing but deeply-insightful op-ed about the state of mathematics education in Atlanta public schools. He’s recently been interviewed in a three part series in Black Enterprise about his role as an NSF program officer. The below quote is from Part II — I recommend the whole series.
The most significant challenge facing STEM education and the workforce is the capacity of the U.S. educational system to produce interested and qualified participants in the STEM enterprise. Here is where the racial and socio-economic challenges facing the nation are most glaring.
According to the National Center for Education Statistics National Report Card, there are some damning realities that significantly challenge STEM education and the STEM workforce. In 2015, only 33% of all eighth grade students in the U.S. were proficient or better in mathematics. Only 13% of black eighth graders and 19% of Hispanic eighth graders were proficient or better in mathematics, which is in contrast to 43% of white students and 61% of Asian students. For students who live in poverty and qualify for the National School Lunch Program, only 18% were proficient in eighth grade mathematics.
According to the College Board, only 16% of black students are college or career ready by the time they take the SAT in eleventh grade. For Hispanic students, 23% are ready. For Asian and white students, 61% and 53%, respectively, are ready for higher education or to take on meaningful work. This landscape is a problem.
Getting closer to “all” in #CSforAll: Instructional supports for students with disabilities in K-5 computing
I’ve been arguing for a while that we don’t know how to get to CS for All, because we don’t know how to teach “all” yet. This is what the Bootstrap group has been arguing from a STEM discipline and economics perspective (see blog post). I’ve also been concerned that we’re biased by the Inverse Lake Wobegone Effect and are assuming that the high-ability learners we’ve been teaching represent everyone.
Maya Israel is one of the few researchers who’s asking, “How do we teach computing to students with cognitive or learning disabilities in K-12?” Below is a link to her most recent study. Here, she’s looking at how we teach, what helps the students to engage in the computing activity. I talked with her about this paper — we still don’t know what the students are learning.
As computer programming and computational thinking (CT) become more integrated into K-12 instruction, content teachers and special educators need to understand how to provide instructional supports to a wide range of learners, including students with disabilities. This cross-case analysis study examined the supports that two students with disabilities, who were initially disengaged during computing activities, received during computing instruction. Data revealed that students’ support needs during computing activities were not CT-specific. Rather, supports specific to these students’ needs that were successful in other educational areas were also successful and sufficient in CT. Although additional studies would need to be conducted to ascertain the transferability of these findings to other contexts and students, our results contribute evidence that students with disabilities can and should participate in CT and be provided with the supports they need, just as in all other areas of the curriculum. We present a framework for evaluating student engagement to identify student-specific supports and, when needed, refine the emerging K-12 CT pedagogy to facilitate full participation of all students. We then offer a list of four implications for practice based on the findings.
GP is a new blocks-based programming language being developed by John Maloney (most well-known for developing Scratch), Jens Mönig (developer of Snap!), and Yoshiki Ohshima (one of the developers of Squeak EToys) in Alan Kay’s group. They are all part of the new partnership between Alan Kay and Y-Combinator Research: HARC (Human Advancement Research Community). GP started in the SAP-funded CDG (Communications Design Group).
GP is not yet released, and there’s not much publicly available on it yet. The GP Team published a paper and poster in the Blocks and Beyond Workshop at last year’s VL/HCC on GP. The best introductory article on GP so-far is on the Scratch Wiki at MIT based on John’s presentation at the Scratch conference last year.
GP is an exploration of the question, “How far can we go with a blocks-based programming language? Do we have to move students to a textual programming language to let them develop everything from data analyses to real applications?”
GP users can do a lot with GP’s built-in blocks. However, as they grow in mastery, some users may wish to add new blocks to GP (e.g. to manipulate images), or even to extend the GP programming environment itself (e.g. by adding an image editor). GP is designed to be extended in itself using the same blocks language that users already know. However, unlike Smalltalk or Snap!, the GP language itself cannot be extended (e.g. to add a new control structure) without modifying the virtual machine. Keeping the GP language simple and fixed is intended to ease the learning path for beginners.
A brief tour of Smalltalk-like features of GP
When you first start up GP, it looks like Scratch. The blocks palette is different, because it’s covering a larger space of blocks. GP includes blocks for dealing with data (e.g., JSON, comma-separated values), media generation and manipulation, connections to the network and external devices, and the ability to create and coordinate multiple objects.
There are even blocks in there for manipulating pixels in an image and samples in a sound. GP is the first blocks-based language in which I’ve been able to do both sound and pixel Media Computation examples. I built the first version of MediaComp blocks for GP, then John figured out which ones were actually useful and then re-implemented them in GP much more efficiently than what I did.
I’m introducing GP here with the GP Team’s permission in order to show you a prototype ebook I’ve been building the last few months. You can play with GP at http://home.cc.gatech.edu/GPBlocks. This is the browser-based version which is offered with no guarantees — the browser version will likely change dramatically as GP is still being developed, and even the examples in the ebook may break over time. (Note: These browser-based examples are best viewed in Firefox on a desktop or laptop computer; they do not yet work on iOS or Android tablets.)
Here’s a brief series of snapshots to give you a sense of what makes GP so interesting and powerful compared to most other blocks-based languages. In the stage area (upper right-hand corner) right-click (control-click on a Mac) to bring up the stage menu.
The menu options for a workspace and to browse will elicit warm feelings of recognition for Smalltalk and Self programmers. Go ahead and click on the browse menu item.
Scanning the classes along the left hand side you realize that this is a full Smalltalk-like language. All the pieces are there and inspectable. The middle panes show the instance variables in the class (top) and the methods for the class (bottom). The rightmost pane shows the code for the method — in blocks!
One of the big goals of GP is that all of GP is written in GP. Even the lowest levels of GP (e.g., how bitmaps and blocks are constructed) can be manipulated in GP, all in blocks. Those methods are real code and “live.” Change them and you change how GP is working immediately. Right now, that’s super dangerous — there is no “editing” mode. Move a block out of place, and the method is changed at that moment. Beware of re-defining how Integers work! The GP team is currently working to complete this part of GP, allowing the GP programming system to be used to modify itself, like Smalltalk.
The GP team is also exploring the stages between blocks and text. At the top right hand corner of GP is a slider between blocks and text. Switch it to text, and all of GP is presented and usable in a textual form. (There’s even an interesting middle stage between blocks and text.)
I’ve been using GP for about nine months. During the Spring semester, I’ve been using GP with an undergraduate research assistant, David Tran, to build a prototype of a new kind of ebook structure. Play around (muck/MOHQ around) in the GPBlocks MOHQ, and in the next blog post, I’ll explain what it is and what we’re exploring in it.
My thanks to the GP team for review and comments on drafts of this post.
Last month, NSF hosted a STEM Education video showcase. I was surprised at how much I enjoyed and learned from these. They’re only 3 minutes each, so it’s a brief investment in getting a sense of a project — and there are a lot of interesting projects here. Here are some of my notes on what I found that was cool:
- You can find the CS education videos here, but there’s a lot more relevant stuff beyond that category, like the videos on integrating STEM and CS.
- Jill Denner’s video on the Digital NEST changed my mind about the role of informal education in broadening participation in computing. I’ve worried that afterschool computer clubs and MakerSpaces are mostly for the privileged (as in this blog post). Jill’s video was a compelling picture Hispanic/Latino/a youth in technology education.
- Learning scientists are increasingly exploring the role of embodiment in learning. The project on integrating dance and CS was the first example that I’ve seen in how to do this in CS — exciting work!
- I was pleased to see Sarah Wille’s work on providing computing education to students with learning disabilities. It’s a really important area that we need for CS for All. I have worked with Sarah on BASICS and didn’t know about this project.
- Celine Latulipe had a video on her lightweight teams that she uses in a Media Computation class (yay!) which is a short version of her SIGCSE 2016 paper.
- Sara Dunton did a great job organizing the ECEP video.
There are a lot more great videos, but I’ll stop there. Highly recommended viewing!
Medieval guilds were associations of craftsmen who carefully protected who had could practice the craft. In the end, they faded away because (as Wikipedia describes), “the guilds negatively affected quality, skills, and innovation.” The economy grew after the guilds faded away.
The below linked article in TechCrunch is an example of programming craftsmen protecting their turf, the way that the guilds did hundreds of years ago. I have responded to some of these complaints before, like the one that suggested that people should just be users and not programmers. “You can’t do it as well as we can” and “you’ll just make a mess of it” are the kinds of complaints that professionals have made over the centuries to keep others from adopting their practice. Of course, both of those are correct statements, as they are true whenever you’re talking about learners. They are correctable problems.
The below quote is particularly aggravating because it says that programming is only right for a certain “type of person.” For the technology industry, that usually equates to privileged white or Asian males.
When has it ever worked to say, “You shouldn’t learn X” especially if X is valuable and useful?
Don’t get me wrong; I do believe that engineering and programming are important skills. But only in the right context, and only for the type of person willing to put in the necessary blood, sweat and tears to succeed. The same could be said of many other skills. I would no more urge everyone to learn to program than I would urge everyone to learn to plumb.
My Blog@CACM post this month is on the AAAS symposium I attended on undergraduate STEM education (see post here). The symposium set up for me a contrast between computing education and other STEM education. In math and science education, faculty are more likely to get continuing professional development and to value education more than CS faculty.
Why is it different in CS? In the blog post, I suggest that part of the issue is maturation of the field. But I have another hypothesis — I suggest that most CS teachers, especially at the undergraduate level, don’t think of themselves as teachers.
In my book Learner-Centered Design of Computing Education, I use Lave & Wenger’s situated learning theory as a lens for understanding motivations to pursue computing education. Lave & Wenger say every learner aims to join a community of practice. Learners start out on the periphery of the community, and work their way towards the center, adopting the skills, values, and knowledge that those in the center hold. They might need to take classes because that’s what the community values, or maybe they do an apprenticeship. The community of practice provides the learner and the practitioners a sense of identity: “I belong with this group. I do this practice. This is who I am.”
Lijun Ni taught me the value of teacher identity. Someone who says “I’m a math teacher” (for example) will join math teacher organizations, will seek out professional development, and will more likely be retained longer as a teacher. That’s their identity.
I believe that many science and math teachers (even at the undergraduate level) feel a sense of identity as teachers. Even at research universities, those teaching the intro courses in mathematics and science are likely teachers-first. They know that they are mostly no preparing future mathematicians, biologists, chemists, and physicists. They are preparing students for their chosen professions, perhaps in engineering, medicine, or computer science. The math and science teachers belong to a community of practice of teachers, e.g., they have a goal to be like the best teachers in their profession. They have an identity as teachers, e.g., they strive to be better math and science teachers.
I suspect that CS teachers feel a sense of identity as software developers. They see themselves as programmers primarily. They see themselves as producing future programmers. They take pride in what they can do with code. They have a sense of guardianship — they want the best and brightest in their field.
There’s a difference between CS teachers as programmers vs CS teachers. Programmers train other programmers. They learn new programming languages, new techniques of programming, the latest tools. Teachers teach everyone, and they learn how to be better at teaching. We need CS teachers to be teachers. It’s less important that they know the latest industry gadgets. It’s more important that they learn how to teach “all” about CS, and how to teach that CS better.
When Grady Booch came to SIGCSE 2007, I was surprised at how excited everyone was — people still talk about that visit (e.g., see the explanation for the BJC approach to computing). I realized that, for most of the people in the room, Grady was a role model. He was at the center of community that they most cared about. Note that Grady is not a teacher. He’s an exceptional software engineer.
There are serious ramifications of a teacher with an identity as a software engineer. I had a discussion a few months ago with one of our instructors, who told me, “I just don’t get why women would even want to be in computer science. Working in a cubicle is not a great place for women to be! They should get a better job.” I was shocked. I didn’t tackle the gender issues first. I started out trying to convince him that computer science doesn’t just lead to a cubicle. You could study computer science to become something other than a software developer, to work somewhere other than a cubicle. He wasn’t buying my argument. I realized that those cubicle jobs are the ones he wants to prepare students for. That’s where he imagines the best programmers working. He doesn’t want to teach computer science for whatever the students need it for. He prepares future programmers. That’s how he defines his job — a master software engineer with apprentice software engineers.
I am calling out undergraduate CS teachers in this post, but I suspect that many high school CS teachers see themselves as software developers (or as trainers of software developers), more than as teachers of computer science. I hear about high school CS teachers who proudly post on the wall the t-shirts of the tech companies who employ their former students. That’s a software developer focus, an apprenticeship focus. That’s not about teaching CS for all.
What would it take to shift the community of practice of CS teachers to value teaching over software development? It’s an important change in perspective, especially if we care about CS for all. Not all of our students are aiming for jobs in software development.
How did other STEM disciplines do it? How did they develop a culture and community of practice around teaching?