Campbell’s Law <http://bit.ly/hMsyUr>: “The more any quantitative social indicator is used for social decision making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor.”

Such anomalies surfaced in Washington, D.C., and each of the states — Arizona, California, Colorado, Florida, Michigan and Ohio — where USA TODAY analyzed test scores. For each state, the newspaper obtained three to seven years’ worth of scores. There were another 317 examples of equally large, year-to-year declines in an entire grade’s scores.

USA TODAY used a methodology widely recognized by mathematicians, psychometricians and testing companies. It compared year-to-year changes in test scores and singled out grades within schools for which gains were 3 standard deviations or more from the average statewide gain on that test. In layman’s language, that means the students in that grade showed greater improvement than 99.9% of their classmates statewide.

The below article appeared in Brown University’s Daily Herald newspaper, in response to the article I blogged about a few weeks ago (thanks to Steven Sesko for this). I don’t see “unflattering statistics” in the original article, but I’m not a female in CS at Brown — some of the statistics about under-representation might be perceived as “unflattering.”

It’s a hard place to be in. In highlighting the many who aren’t there, and bemoaning the small numbers, we may make those that are there feel diminished. I think we should highlight how male CS has become, and ask if there’s a problem that needs to be addressed. NCWIT is fighting a good and noble fight. But I understand that it’s a fight that must be fought delicately, trying hard not to be unflattering to the women in CS now.

There are fewer women than men in the CS department. Yet quantity and quality are not one and the same. The excellence of female students’ departmental contributions is in no way limited by the number of female students — nor is our love for the subject. Writing articles that broadcast the unflattering statistics regarding women in CS and fixate on the trials and tribulations they face, but that do not also mention their joys and successes, is a damaging and reactionary way to dishearten potential computer scientists. The two of us love what we do and want others to join us, not for the sake of boosting the numbers, but so that they can experience first-hand a subject that is uniquely exciting and rewarding. We sincerely hope that after reading this piece, no student — male or female — feels discouraged from exploring the fascinating field of CS.

At the CE21 Community Meeting, I heard people talking about the great things that they’re doing in their classroom, and how they are looking for education researchers with whom they could collaborate for a CE21 proposal. That’s a great idea, and making that happen was the point of holding the community meeting. But I offer a piece of advice: Go beyond your classroom. Work in multiple classrooms. Don’t collect data for your study in the classroom where you’re teaching.

My colleague Amy Bruckman told me that, at MIT, the Human Subjects Review Board will not allow a researcher to gather data on his or her own classroom. There is an inherent conflict-of-interest, if you are studying your class and teaching your class. As a teacher, you want to do everything you can to support your students’ success. As a researcher, you have to do certain things and not do certain things, so that you can conduct your study.

The SIGCSE Symposium is mostly faculty studying their own classroom. That works fine if the goals are to develop better teaching practices, to do a fair assessment of what you are doing, and to share it with others. That’s called action research and has a lot of benefits for teaching practice. But that’s not what I read NSF as wanting from CE21.

CE21 is supposed to be rigorous education research, in a computing education context. It’s serious research with serious funding. If you’re a serious researcher, then one of your first questions is where you should best do the research you want to do. Your classroom is a great place to get ideas. It’s never a great place to test your ideas. You should test your ideas so as to convince others — testing in your class is akin to saying, “See! It worked for me!” That’s not convincing.

If you have a great idea that you want to develop and test with a CE21 grant, then find some collaborators. Convince a colleague to work with you, to test your ideas in someone else’s classroom. If you can’t convince someone else to work with you, you’ll never convince a review panel to give you money to develop and test your ideas.

When I’ve made statements like this in the past, I sometimes get push back: “I’m at a small place. I can’t go off to do research in somebody else’s classroom! Sometimes, there isn’t another classroom!” If that’s the case, in my opinion, the NSF CE21 program is not for you. (I’m not an NSF program officer, but I do get funding from and review for the Education side of NSF, so I have some insights into what NSF considers serious education research.) CE21 is trying to bring significant resources to do high-quality, critiquable research to advance the state of our understanding about computing education. In particular, CE21 is about trying to advance the CS10K agenda, which means your best bet is to be working with high school teachers and students. Whatever you propose, go beyond your own classroom.

I talked to people about the new Carnegie Mellon University curriculum last week, but no one to whom I spoke made such a strong statement as below, that OO is being “eliminated entirely.” I was pleased to hear that the new curriculum is multi-lingual and multi-paradigmatic. I’m not sure how the curriculum can be entirely OO-free since the first course is in Python. I know that the second course is in C0 (“C not”), and the third course is in ML. The report that the below blog post links to is much more careful in its claims about object-oriented programming. I did a Blog@CACM post, using the post below as an example, about how we polarize discussions in computing education rhetoric — the CMU report on the new curriculum is much more reasoned (in its analysis) and reasonable (in its recommendations).

Object-oriented programming is eliminated entirely from the introductory curriculum, because it is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum. A proposed new course on object-oriented design methodology will be offered at the sophomore level for those students who wish to study this topic.

I had a reporter talk to me recently about women in computing. I rattled off statistics to her, and told her about curricular and “Georgia Computes!” efforts. She was all “yeah, yeah, yeah” then asked me if I knew about real women in computing, especially women in my classes. I told her that I mostly teach non-majors, but was learning interesting stories about the impact of our introductory course on their lives. She loved those, and encouraged me to share them, so let me tell you two here.

Anne was a senior when we taught the Introduction to Media Computation course the first time. (Lots of seniors had been putting off their computing requirement until their last year, hoping that something better would come along.) She sat in the second row, right in the middle, and asked me questions every lecture. I’d use her frowns as an indication that I wasn’t making sense yet in lecture. After she finished the class, she came to see me. “I’ve always wanted to TA a course, but never had the time before. Now, I’m about to graduate. Could I TA this course during my last semester here?” Since she was a good student, and I really needed to get more female TA’s (my pool of undergraduate TA’s were mostly male in the beginning), I gladly agreed.

During that semester, Anne did a great job as a TA, and as a Senior, she got some terrific job interviews — better than she expected. In fact, she was getting interviews that her peer Accounting majors weren’t getting, even when they had better grades. She finally asked a recruiter, “You know, my grades aren’t that good. Why did you interview me?” The recruiter told her, “You’re an Accounting major who can TA a CS course? You must be amazing!” She was hired by a firm that focused on IT, and when I last saw her at an alumni event a couple years ago, she was with an IT firm in their accounting department. She is making a career of the subject that she simply wanted to try as a TA.

Rachel was an Architecture major who took the introductory course because it was required, did really well, and then became a TA for the course. With 300+ students every semester, and a desired 25:1 student:TA ratio, we need a lot of TAs. She helped teach Python and HTML (e.g., we write Python programs that generate HTML).

I know Rachel because she and her family go to our church. She took a job with a construction firm right out of College, and did well for several years. Then the Recession hit. She was out of job for awhile, and even talked to Barb about going back to school to become (really!) a high school computer science teacher. Then, she got a job in Web Design. That was two years ago. She came to one of the performances of our play in February, and I got to catch up with her. She’s still doing Web Design and loving it. She was just teaching herself Ajax, and enjoyed the opportunity to learn and use new things.

What’s most interesting about both of these jobs is that these women probably both count as women entering the IT field — but neither started there. Neither of these is a story about a “pipeline” from high school to college to job in IT. Neither became CS majors. Rather, both of these are about opportunities that arose from having a computing class, that each discovered she enjoyed and was good at. They followed the majors that they wanted, but ended up in IT. That was a door that got opened for them because they had to take a required freshman course on media computation with Python.

One of the ongoing battles in CS Education is whether or not to teach how data structures are built. One school of thought goes something like this, “We have to teach how data structures are really implemented, because unless you realize how the runtime behavior differs between a singly-linked list and a doubly-linked list and a tree, you really can’t make informed choices between them.” In other words, we teach the implementation to inform the use. An opposing school of thought says, “It’s ridiculous to have anyone implement yet another of these complex data structures! How many linked list implementations do we need? Instead, we should focus on how to use them well.” That school of thought sees data structures as a programming or even vocational benefit. Several colleagues in computing education wrote a nice piece describing the intent of teaching data structures, which differ from teacher-to-teacher.

Based on interviews with Computer Science educators and analysis of CS literature, we identified five categories of intent: developing transferable thinking, improving students’ programming skills, knowing “what’s under the hood”, knowledge of software libraries, and component thinking.

I’ve come to realize that I have another reason for teaching the implementation of data structures, which I don’t think is covered by the five reasons in that piece. It’s only through dealing with implementation structures that I (and my students) have seen their misconceptions highlighted, like the ones I talked about in my ontological categories post. I continue to struggle with my students’ understanding of object, variable, reference, and “link” (the arrows we draw between boxes in data structure diagrams). We have wonderful discussions now, where we talk about the best visual representation for various structures — great “meta-level” discussions to have.

I think they’re starting to get it (and I have these peer instruction results, so that I can make that claim with some confidence), but it’s a real struggle. Moving from singly-linked lists to doubly-linked lists helped face the problem well: It’s too easy to simply say, “Well, that’s just the next node,” and gets more complicated when students have to say, “That node is the next of the previous, and the previous of the next” and now start to wonder what those words mean. “Next” has a commonplace meaning. We don’t talk about the “next” and the “previous” at the same time in our daily conversation, but we have to deal with both simultaneously when implementing them.

I had a chance to discuss these issues yesterday with some really great cognitive and learning scientists. Some pointed out that the problem is all the harder because there’s no there there — all these words, all these ways to refer to objects, are just different perspectives, and there’s no real solid thing that’s being described. I countered that there was a real, inspectable, testable thing: the actual values in real memory addresses. That argument didn’t hold much weight with them, because few of us really use that level. Things are defined through their use, and different uses lead to different definitions, and might as well be different things. “Explaining memory is just layering yet another perspective, and that one has even less usefulness than the others and is even more complicated. ” They thought that it’s like teaching quantum mechanics to fourth graders so that they have a scientist’s understanding of heat.

I’m not convinced, but at a higher level, I’m interested by the kinds of arguments we’re having. These questions of “what is our intent in our teaching?,” “what’s real?,” and “what does it mean for something to be ‘defined’?” seem esoteric, or worse, pointless for the in-the-classroom CS teacher. Those are questions for navel-gazing philosophers, we might think. Actually, they are the answer to some of our fierce debates in computing education. Why do we teach data structures? Why do we teach hardware, architecture, and memory structures? I’m sure that we all have immediate answers that we whip out in undergraduate curriculum committee meetings. What’s our evidence for our answers?

The cognitive scientists were asking us to consider, “Does it really make sense any more for computer scientists to understand the computer down to the metal?”

I’m asking us to consider that maybe the reason to teach data structure implementation has no practical or vocational benefit — an important purpose is just to highlight and correct what students don’t understand.

I met with Jeannette Wing yesterday, and we discussed the need for a good, authoritative definition of computational thinking. I told her about the CE21 Community Meeting where I saw K-12 evaluators looking for a definition that they could use to develop an assessment of computational thinking at the middle school level. Some of these evaluators were using the CS:Principles materials which made me uncomfortable — we designed those principles and practices to reflect what we saw as the core of computer science and as being appropriate for an advanced placement course. We didn’t write these to be a guide to what middle school students need to know about how to think about and with computing.

She gave me a copy of the most recent The Link, a CMU publication, in which she has an article, “Computational Thinking — What and Why?” She offers a definition and a rationale for the definition, taken from a work-in-progress paper by Jan Cuny, Larry Snyder, and Jeannette, “Demystifing Computational Thinking for Non-Computer Scientists.” She gave me permission to blog on the definition and the rationale.

Computational thinking is the thought processes involved in formulating problems and their solutions so that the solutions are represented in a form that can effectively be carried out by an information-processing agent.

The article goes on to expand on this definition and offer examples. She says, “Computational thinking overlaps with logical thinking and systems thinking. It includes algorithmic thinking and parallel thinking, which in turn engage other kinds of thought processes, such as compositional reasoning, pattern matching, procedure thinking, and recursive thinking.” Jeannette pointed to a section of the paper on “Benefits of Computational Thinking” as being key:

Computational thinking enables you to bend computation to your needs. It is becoming the new literacy of the 21st century. Why should everyone learn a little computational thinking? Cuny, Snyder and I advocate these benefits [CunySnyderWing10]:

Computational thinking for everyone means being able to:

Understand which aspects of a problem are amenable to computation,

Evaluate the match between computational tools and techniques and a problem,

Understand the limitations and power of computational tools and techniques,

Apply or adapt a computational tool or technique to a new use,

Recognize an opportunity to use computation in a new way, and

Apply computational strategies such divide and conquer in any domain.

Computational thinking for scientists, engineers, and other professionals further means being able to:

Apply new computational methods to their problems,

Reformulate problems to be amenable to computational strategies,

Discover new science through analysis of large data,

Ask new questions that were not thought of or dared to ask because of scale, but which are easily addressed computationally, and

Explain problems and solutions in computational terms.

This definition is still pretty high-level, but is still much better than having no definition. It’s a broad definition that encompasses a lot of powerful cognitive skills. We can move away from trying to draw lines between what is and what isn’t computational thinking, and instead focus on implications. What parts of this are appropriate to see at the middle school level? How do we teach these abilities? How would we measure them?