Social power in computing and its affect in early CS education

Reading a NYTimes piece this morning that summarized work on how people tend to dismiss those with less social power in a given situation.  The article is unfortunately titled around money, even though the point of the article is much broader, looking at the implications for public policy if high-power people dismiss those below them.

I'm thinking about the impact of this in education, particularly in my own field of computing.

Much has been written about the nasty or dismissive culture of computing and its role in hampering diversity. Much has been written about how early encouragement was key for many women in the field (citing women simply because I'm familiar with writings on women in CS); this was a key component of last week's NYTimes piece on Women in Science.  The surface-level connection between these themes seems clear, but I've never understood the underlying mechanism that makes computing culture somewhat abrasive.  The social power piece leaves me wondering how we define social power in computing, and how that evolves over the span of a degree program or career.

My sense is that early on, we equate social power with programming ability in some abstract sense: those who can crank out code quickly, know arcane commands, and never need to reference a manual are granted power and status.  The "social" power here comes from these folks being able to act as human manuals (if you can muster the nerve to approach them).  As computing assignments and projects grow richer so that programming is more a mechanism and less the whole picture, new forms of social power emerge.  By then, of course, many of those who struggled with the first definition of social power have dropped out.

CS educators are increasingly thinking about how to broaden the perspective of computing in intro courses: get beyond programming and into applications, requirements, ethics, etc.  This is a great first step.  But if social power theory applies here, then these efforts will only have impact of courses can create a similarly broad social power structure.  Exercises that talk about broader issues but then have students primarily express their ideas in code won't challenge the core problem.  Expanding what we talk about in classes targets an individual's perspective on computing; changing what we visibly value and celebrate in our courses targets the social communities that yield broader groups of computing professionals.

How often do we talk about instructional design for shaping communities rather than individuals?  If anyone has pointers into literature on this for computing, I'd like to hear about it.

Mediating Differences in Computing Skills in the same Classroom

I just came across Ross Penman's post on the problems of computing education.  Ross is a 14-year old web programmer from Scotland.  His description of his school's computing curriculum is depressing, particularly the descriptions of the various ways in which it inadvertantly turns students off from computing.  These ways include the impact of old software and technologies that yield inferior-looking products (in the web-design or video-production spaces) and programming tools with low ceilings (in this case, Scratch), which aren't able to hold the interest of students who grok programming and want to do more with it, faster.

The latter point particularly got to me.  In our drive to providing computing education for most students (a good thing), we can't afford to alienate the students who will actually be good at it.  Many comments on his post are from professional programmers advising him on how to learn on his own.  That's reasonable advice for a student with Ross' abilities to teach himself, but it completely misses the point: what do you do for the students who have similar potential to Ross, but not the confidence, drive, or established interest to do this on their own?  Our curricula need to engage and foster them!

A key part of the problem here is how to gracefully handle the wide variation in both teacher and student abilities in computing: variation in student abilities is wide, the knowledge gap between some students and their computing teachers is also wide.  How do we enable teachers to work with such a wide-ranging class, including students who are more comfortable (or skilled) than the teachers?

Teachers need curricula that they can use on an entire class, but that (a) accommodate a wide range of student abilities, and (b) are sufficiently within the teacher's comfort zone to be usable.  The community seldom talks about (b), but we can't ignore its impact on adoption and effectiveness of computing education.

Our current standard early-programming solutions, such as Scratch and many of the other drag-and-drop tools, are too far skewed to the lower-middle end of (a) while achieving (b).  The problem isn't drag-and-drop per-se, but the limitations of the languages and tools that get created around drag-and-drop.

What if we had a curriculum (with language, software, materials, etc) that provided a simple, beginner-friendly approach to writing basic programs, but that scaled---within the same framework and tools---to more sophisticated programs that exercised more advanced computer science concepts?   Teachers could focus on learning to teach the core framework; most students could learn computing at the level of the basic programs, but students who are doing well could go forward without having to go off entirely on their own (and staying within the realm of what the teacher recognizes, for various benefits).

Program by Design (PbD), which we have worked on for 20 years, was designed for the sort of smooth ramp-up that accommodates learners at all levels.  The world-programming infrastructure within PbD developed the basic framework of programming animations, websites, and other reactive systems using a small set of constructs.  Bootstrap adapts animations programming in world to the needs of middle-schoolers and teachers who are new to computing.  In this ecosystem, a teacher can cover the core world-programming framework with the entire class.  Interested students can get into more advanced computing concepts by creating animations with richer features (multiple similar characters to get into lists, etc).  But these advanced students are still in the tools and approach that the teacher knows, which makes for a smoother curricular experience all around.

Some of our papers describe the underlying model, tools, and curricula.  There are some rough spots to the way we've packaged these curricula in the past, which we are actively working on.  But the fundamental idea and inspiration remains: our challenge as computing educators is to create tools that (a) accommodate a wide range of student abilities, and (b) are sufficiently within the teacher's comfort zone to be usable.  We hope others will join us in trying to meet this challenge.

Resurrecting a blog, a professor, and a course

I'm now on sabbatical, next due in the office in August 2014.  Been thinking this would be a good excuse/motivation to resurrect the blog (quiet for the last 5 years), but hadn't yet found something I felt like writing about.

So much for leaving the classroom: my inaugural sabbatical post is about class sizes.

The NYTimes has an op-ed on whether class size counts.  The article is about pre-college, not college classes.  Roughly, the piece discusses a proposal under which high performing teachers get additional pay in exchange for taking on larger classes.   The piece doesn't discuss how much larger, but does cite a national survey that asked teachers about taking on 3 additional students in exchange for $10K.  Interestingly, only 42% of teachers wanted this deal, while 47% would turn down the raise in exchange for 3 fewer students.  The piece also discusses the lack of actual research on the effect of class sizes, noting that the effect may be quite different for different kinds of students.

This struck me in part because my department is potentially facing an increase in students interested in taking Computer Science next year.  For the past three years, I've taught the second course in our CS sequence (OO program design and data structures), last year topping out at 235 students across two lecture sessions and 9 lab sections.  And honestly, trying to find ways to give the support associated with smaller classes to that many students burned me out enough that I'm only now really figuring out what I want to do with my sabbatical.

But it has left me thinking a lot about what we associate with "small classes", what parts of that actually matter, and how we can provide it as class sizes outstrip resources.

Access to help is perhaps the biggest issue.  In practice, though, help needs are not directly proportional to class sizes.  How many times have I taught smaller (40ish) person classes and not had a single student come to office hours or request appointments?   Out of my 235 students, I'd estimate that there were roughly 25-30 students who actually came to my office or asked for help with any regularity (I know many more used the teaching assistants).  The point is that a class of 200+ students who don't need help is a very different beast than a class of students who do need help.  The op-ed raises this distinction, but at the college level, we seem to make our allocations more on simple student/staff ratios.

Quality feedback on student work follows close behind.  Good teaching involves showing students who don't think they need help that they still have things to learn.  Unless someone is actually reading student work, we miss those opportunities for deep education.  I still insist on having my staff actually read all the code that gets submitted (rather than just auto-grading against test suites), but we're losing the scale battle there.

Avoiding anonymity is another issue I worry about: even if a student never expects to seek help, large classes feel impersonal.  At a time when students are trying to work out who they are and what they care about, this is problematic.  Not problematic enough, however, to justify additional resources.

I will be spending at least part of my sabbatical better understanding how cognitive tutors and other computer-based learning aids could help with these problems.  I don't want to fully automate my class.   Being honest with myself, I'm looking for ways to mitigate the guilt of not being able to support each and every student in line with my values as a teacher.  Having that support come entirely from a human teacher isn't feasible, nor do I suspect necessary, or even optimal.  There are interesting blended human-computer instructional systems waiting to be built for teaching in large classes (lots of progress exists on the systems side, but the teacher/tool interaction seems less developed).  If I can come off sabbatical more comfortable with the level of support I can provide, and rested enough to hold up my end of the bargain, I'd call it a success.

The music of teaching

Between the end of classes last week and a paper deadline next week, I haven't done much outside of work lately. Last weekend though, I treated myself to a favorite spectator event: a master class in music. In a master class, music students perform for a master (usually renown) musician, who works with the student to improve the performance. The audience gets to watch the whole exchange, which lasts 30-45 minutes per student.

Music master classes thrill me on many levels. As a teacher, I envy the masters: they hear the effects of their teaching in real-time (and the difference is usually dramatic, easily noticeable even to my amateur ear). A student can play the same 30-second excerpt over and over with different voice or emphasis each time. Each time, the piece and the process become more alive. What reward must lie in such interaction. In teaching programming, writing the same code over and over in different styles is tedious; once code is written once, writing the same code again with minor variation doesn't offer insight that's worth the time or trouble.

As one interested in the structure of software systems, I'm intrigued by how the masters move students between thinking high-level and low-level, between thinking compositionally versus decompositionally. The first student played a piece with technical precision but not much emotion. The master helped her find and emphasize local melodic patterns within the overall piece. The second played with incredible emotion and intensity, but without an overarching organization to the emotion to carry the listener through the piece. The master helped him find a story across the piece and to refine his playing to draw that out. These students are experimenting with ways to interpret a finished product (the composed piece). I work more like the composer in trying to create the piece in the first place. When I'm done though, at best most people interact with a small portion of what I've created (the user-interface, not the underlying code). A computing system needs to be fairly complex to give a user a large space in which to interpret the result; music students, in contrast, can work on interpretation even from the smallest pieces. The route to exploration is much shorter for the student.

I'm reminded of the interplay between high-level and low-level thinking this weekend as I bury myself in writing a paper. I love this process: moving ideas and results over and around in search of the story and emphasis that makes an idea come alive for a reader. This part of my job gives me real-time experimentation with organization and presentation (with more chances to get it right than when I lecture). I often wonder if I would enjoy this career without the writing aspect. Coding is similar, but far less forgiving: programming is sensitive to unfinished parts in ways that writing (or music) is not.

Master music classes remind me what interactive teaching can be for both teacher and student. Can we bring that spirit into teaching computing and programming? Does it make sense to do so? I hear more and more that students reject computer science because of the long detailed hours. How do we teach to expose more of the intermediate rewards? What would a master class in computing look like? My best vision right now involves a lot of shell scripting, which could be cool but only applies to a limited range of programming tasks. What about a master class in software modeling? The right notes must be there, if we can figure out how to scale them to computing education.

Punching lines: what prevents change?

Quote: "The barrier to change is not too little caring; it is too much complexity." -- Bill Gates, Harvard University Commencement 2007

I came across Gates' address a couple of days ago and highly recommend it. It's forceful, and this line pulled the main punch. Gates argues that many people are concerned about global issues such as economic inequity, but the problems are so complex that we don't know what to do about it. Cutting through the complexity is one of the objectives of the Gates Foundation.

I'm often moved by a problem, only to stumble in a wave of helplessness and futility that discourages me from even trying to do something. India did this to me many times; the way it commands me to react is one of the things I find most rewarding about traveling there. Educational inequality sometimes hits me the same way: leveling the academic playing field seems daunting because disadvantaged students have to get beyond the system around them that had the same education they are trying to surpass. The latter is arguably easier to solve; I'm still tossing around whether it is any less critical.

Underneath Gates' complexity theory is an assumption that people need to feel they are having an impact, or at least being useful, to participate in a problem. Measuring impact is hard, especially for a single individual facing a global-scale task. Personally, I find micro-finance appealing because it provides some metric of utility to someone; I just have to be careful not to
think too hard about all of the people I'm not helping. Cliches about butterfly wings notwithstanding, we have a hard time believing in the impact of small acts. Most people haven't been trained to think in terms of large systems, but that's what charitable giving or community service often ask us to do.

This seems an educational challenge: we have enough people with some time or money to give to causes (my sense is that there is more of this available now as the middle class grows, but I could be wildly wrong on this). What tools do we learn for understanding and participating in complex problems though? I don't recall formally learning much along these lines aside from the importance of voting. This is a deeply social question to which computing technologies could be applied. What might we do?

-----
As a side note, the "punching lines" tag reflects a new thread I'm trying for the blog. It'll label posts that respond to a concise quote that socked me in the gut when I first read it. Not lines I understood on re-reading, but ones that made me stop reading then and there and made my mind tingle.

Scientific Value

I recently finished reading Peter Kramer's Against Depression. Kramer is the psychiatrist who wrote Listening to Prozac some years ago. In talks on the Prozac book, he frequently got questions about the tension between treating depression and the suppression of artistic temperament ("what if we gave van Gogh Prozac", for example). Against Depression is his discussion of society's view of depression juxtaposed against the reality of what doctors understand of the disease, or in his terms, "what it is" versus "what it is to us".

That phrasing of the contrast grabbed me. The descriptions of modern understanding of depression were fascinating and unnerving (covering issues such as the way depression alters the brain, how we become more susceptible to it after each episode, and how the disease is really about the loss of resiliency). It is his bigger question, however, about the tension between the scientific reality and our perception of the problem, that I keep thinking about. We see this all the time with scientifically-valid evidence: people don't believe or even absorb something just because it is true. Kramer attempts to explain why this is dangerous in the case of depression.

It reminded me of a science education video I saw several years back: middle school children did science lessons on light and the inability to see in completely dark places. One by one, children who had done well on these lessons were put into a completely dark room and asked whether they could see anything. They persisted in believing that their eyes would adjust soon, thus enabling them to see. Experience (of being in fairly dark places) overrode the facts (of being in a completely dark place). The video was demonstrating how educators have to elicit the experiences or prior beliefs that contradict new knowledge in order to help students absorb new knowledge.

Kramer's case seems both easier and harder to make. Easier because he can explain the realities of depression in terms of vivid human stories to which readers can relate; the human stories give a hook on which the reader can hang the new knowledge. Harder, though, because our society has a lot invested (emotionally) in romanticizing depression. Kramer works hard to distinguish medical depression (which has corresponding brain pathology) from variations in temperament. Lay people often miss the distinction, which in turn reinforces existing misconceptions about the disease.

Heading into the academic year, the book gives a good reminder of the role of existing beliefs in learning and the importance of casting ideas in ways that grab people's attention. Even if you aren't an educator, there's a lot to learn from this engaging and well-written book. It's a good reminder that we should ask ourselves what beliefs we hang on to, what value we ascribe to them, and how that value might contradict more compelling evidence.

Outsourcing begins at home

CRA, the main advocacy group for Computer Science research, recently cited a report on how companies decide where to locate R&D efforts. This is a hot topic in CS circles as perceptions of international outsourcing are at least partly responsible for the dramatic drop in student enrollments in recent years. [Note to students and parents: the perception is overhyped: more IT-related jobs are available now in the US than at the height of the boom according to a taskforce on the subject]. According to the summary, costs are not the main factor behind where to locate R&D efforts. Other economic factors, such as local growth potential and university infrastructure, are also key. If you prefer Richard Florida's view of a "spiky" world to Thomas Friedman's "flat" one, this summary will not surprise you.

This weekend's NYTimes ran an article about public schools' efforts to achieve racial diversity through socio-economic diversity (subscr reqd). While the article mostly discusses how districts have struggled to make this work in practice, it also cites successes in Raleigh, North Carolina, where performance on state reading tests has improved dramatically within traditionally poor-performing racial groups following socio-economic school assignments. The results are attributed to getting more disadvantaged students into schools with stronger cultures of achievement.

It's a fairly similar goal to outsourcing in many respects: establish a stronger innovation culture in countries with developing economies. This strengthens the local economy while creating new markets (and product ideas) for the company doing the outsourcing. The opening of R&D labs in China, India, and other Asian countries by western firms follows this vision. Yet doing this on the international scale induces much hand-wringing in contrast to the praise it induces done within our own borders. Success on both fronts could creates competition for jobs at home, but we fear the international competition more, partly because revenues leave our borders. Perhaps deep down we also believe international groups will make progress faster than our own disadvantaged groups. The CRA-cited report describes different metrics used to gauge outsourcing to developed versus developing economies. Where do our own disadvantaged communities fall in that spectrum?

Of course, investing at home or abroad isn't an either-or decision. The juxtaposition of these articles just reminded me that we talk a fair bit about international economic development, without nearly as much focus on how to foster domestic talent. It seems to say a lot for our problems here at home.

Breaking down the thought process of computer science

Last month, Language Log had a post on how people learn to think like their professions. The article was written by a linguist, reporting on recent books by a doctor and a lawyer. According to the article, doctors and lawyers learn to think like their professions by comparing information obtained from patients/clients against the treatments and case law that they studied in school (I haven't read either book yet). From a computer science perspective, the description resembles searching a mental database for facts that match the situation at hand. The significant challenge here is presumably in figuring out which queries to pose against that mental database, as the queries reflect which components of a situation are likely to be relevant, which need to be explored in tandem, which need to be generalized, etc. Having a good mental database is obviously also important, but the query construction process seems more reflective of how professionals think.

How does this compare to thinking like a computer scientist? As with most disciplines, we draw on experience and compare situations to figure out how to solve problems. Query formation remains a significant component of how we think as professionals: a computer scientist needs to know what questions to ask about performance, security, reliability, usability, and a host of other system-related -ilities. But our mental database construction problem seems more substantial as well because of the volatile, unregulated, and still mysterious nature of computational systems.

Both law and medicine build heavily on precedence and legal bounds on practice; this shapes the space in which they search for problem solutions. Computing lacks the legal regulation of medicine and law (recall Parnas' oft-cited call to replace disclaimers with warranties in software). Many doctors and lawyers deal mostly with cases that fit existing precedents (the challenge becomes which ones to apply, but the diseases or situations themselves don't change as fast as computing technologies). Law seems to deal with fewer interacting agents than medical or computing problems; medicine seems to have a richer set of diagnostics for exploring how treatments behaves than we often have for computing systems. Living organisms also seem more fault-tolerant, on the whole, than computing systems, which are still very brittle. On the flip side, computing systems lack the complexity of the human brain or body, but I suspect more average computing professionals have to confront our limits of complexity on a daily basis than do the average doctors (who can refer patients to specialists for complex cases).

When we train students to be computer scientists, we really need to train them in the science of how discrete (as opposed to continuous) systems break. They need to think about how someone might attack the system, circumvent it, or use it for harm. They need to think about how to keep the system maintainable in light of new features and new technologies. Our mental databases really need as many facts about which decisions lead to what problems as well as which lead to what solutions. This is somewhat true of medicine, but I again suspect that average programmers deal with this more often than average doctors (beyond drug interactions, which are fairly well documented).

Not many computing programs really take the study of breakage seriously. We spend a lot of time focusing on systems that do work, that are correct, that perform well, etc. These are all necessary and valuable. But when your goal is to make something break, you ask yourself different questions than when your goal is to make it work: there's a continuum from "working" to "broken" and the missing questions lie in the middle. How many students really learn to stress-test their code, to inject faults and study code behavior, to put their work in the hands of novice users, to attack others' systems so they can think about how someone might attack their own? We have the luxury of working in a science of the artificial in which we can try to break something without compromising an organism's health. How could we best exploit that opportunity within the time constraints of a university education?

Snail Phishing?

I got a letter on our mortgage company's letterhead requesting insurance information on our condominium building. The letter instructs us to either fax the info (policy number and period, coverage amount, etc) or to log into a website using a PIN included in the letter. Something about the letter failed my smell test when it arrived a few days ago. Last night, I looked more closely.

The company's logo looked like a bitmap image (grainy), rather than an original. The zip code on our unit is wrong (though our mailing address was fine). The url we were to visit wasn't either of the two that I know our mortgage company to use, and the state in the return address from the company matched none of our other documents from them. The letter also claimed its purpose was to ensure "prompt and accurate processing of our condominium insurance", but we hadn't asked anyone to process insurance for us. It just didn't add up.

We were able to construct explanations for most of these oddities: owners don't necessarily live at their properties, so our mailing address and unit address were probably two separate database fields, with one of them entered manually. Collecting insurance info could be outsourced to another company in another state that creates letterhead from bitmaps of its clients' real letterhead. The letter could have been poorly written. And we weren't able to construct a plausible identity attack that would want the insurance info on our whole condo building (as opposed to our unit).

So I called our mortgage company using the number from their website rather from the letter. A maddening sequence of menus later (on which I got the same options at multiple levels), I get to a customer service representative who checks the notes on my loan file and finds no mention that they've requested this info. She advises me not to comply. I ask how I should go about reporting this to their fraud department, but she says they don't have one. Curious now, Shriram called the number on the letter and went as far as the menus that asked for the loan number and all 10 digits of the social-security number (giving dummy values for each). The rest of the call sounded extremely professional.

So, we are left with suspicious practices from the company requesting the info (the full SSN request), instructions not to trust the letter from a mortgage company with no fraud division, and several small signs that our mortgage company isn't as polished as it could be. Friends who have had several mortgages reported being asked for similar info on a regular basis. We are going to return the letter with a note that the mortgage company has no record of requesting this info and advised us not to comply.

There's a real business lesson in here though about how to create the perception of security and trust. If this request is legit, the company has a lot to learn about preempting concerns about identity theft and phishing; if not, they need a fraud department. Either way, the constant hum of data threats raises the stakes on companies that may just be catching up with the infrastructural aspects of IT. These psychological questions will become only more relevant if more people develop the sensors that triggered my night of investigation.

Data literacy is the new R

Catching up on some old Economist issues, I came across an article "Of bytes and briefs" from the May 19th issue. The article was about how electronic communications have raised new questions regarding information discovery in the legal system (such as what must be turned over in a request to produce documents) . The time required to comb e-data for proper disclosure is apparently becoming onerous (read, extremely expensive). The article also cites judges' need for better education about data, so they can better rule on proper discovery practices.

Yet another example of how lack of data illiteracy becomes a societal problem. About a year ago, the "CSI effect" got a lot of press, with concerns that CSI led jurors to expect to much by way of evidence (though the jury is still out on whether CSI is the fundamental culprit). Much as I love CSI, I cringe whenever they show software packages with zooming and search capabilities beyond what is technically feasible. Privacy is of course another big issue here, with people not understanding data provenance and the power and risk of mining algorithms.

Computing has long felt like a "new R" that should join reading, 'riting, and 'rithmetic as fundamental components of basic education. "Computing" is a broad term, though, and mentions of "computer literacy" raise the neck hairs of many a computer scientist given its association with being able to use office productivity software. Useful skills, but not ones meeting the usual requirement for university-level credit.

That led several to propose that 'rogramming was the appropriate "new R": as computation (rather than computers) became fundamental to so many fields (witness biology), understanding what could and could not be computed and automated grew increasingly important. I have a lot of sympathy for this view, and strongly believe that a basic education in computation is essential for anyone working in science, digital media, or other fields whose practice is touched by computers. But I'd never push my parents to learn to program (and hope my sister has finally forgiven me for convincing her to take a CS course her freshman year).

Data literacy, on the other hand, is a much better candidate. It touches everyone who uses modern societal infrastructure. It can be motivated in the concrete (via privacy) and tied to everyday human experience (ie, for CSI viewers). It's timely, as the verb "to google" comes up in casual conversation outside of tech circles. It has substance beyond the more vocational feel of how to use office software. And, unlike programming, it doesn't require hours of practice in building artifacts (which, much as I enjoy it, admittedly turns off many people).

_This_ is the required computing-related material for the masses. Universities should develop and offer it; eventually it should migrate down to pre-college. What would it take to give non-techies a basic education in data mining, privacy, data provenance, search, and information lifespan? Many of us could design a substantive course on this stuff that used programming. How to do it without that, while getting to the level of understanding that programming would enable, is a fascinating challenge.

What's the R then? 'rovenance is the best I have so far. 'rivacy is both too narrow and too broad. Taking a european twist, 'rmatics gets the gist, but lacks verbal flow. Suggestions, either for that or for other topics that should make a data literacy 'rriculum list?

Am I more afraid after Virginia Tech?

[I wrote this in the days immediately after the Virginia Tech shooting, but chose to sit with it a while before posting. I have backdated it to when I originally wrote it.]

The first time I felt afraid of a student, I was a graduate student
assisting in a course taught by a professor in my department. The
professor called my lab and asked me to come to his office with the
gradebook. There, I found a surly-faced student standing with his
back to the door and the professor sitting solemnly facing the door.
The student insisted that he had taken our final exam the day before,
even though we had no record of it, and was demanding a grade for the
course. The gradebook showed no grades on any assignment for the
student. The student claimed we had lost them too, and that we were
doing so deliberately. The professor offered the student an empty
room and paper on which he could write descriptions of the exam
questions from the day before. The student remarked that he'd left
his car running and couldn't do that. The professor said he could
offer no more. The student left. I felt shaken, but said nothing.
Years later, the professor told me that that incident marked the only
time he'd been afraid of what a student might do.

The second time I felt afraid of a student, I didn't know his or her
identity. All I knew was that a student was angry enough to write a
strong and sexually-explicit paragraph on my teaching evaluation. I
received this months after the course was over, but still kept an eye
over my shoulder in the parking lot every day for the next two weeks.

The third time I felt afraid of a student, I was attempting to sort
out a dispute between students attempting to work together on an
assignment. One of them seemed disconnected, overwhelmed, and afraid
yet unwilling to face it. His academic advisor confirmed that the
student's behavior was worrisome in other settings as well, and they
were attempting to work on it. I breathed a sign of relief when he
scored enough points to pass the course.

What happened at Virginia Tech is horrifying. As the details came
out, I began envisioning my own usual classroom, with no desks and too
many doors for those inside to reasonably secure. I sensed full-body
memories of interactions with students that set off a little voice in
my head: is this student okay? Perhaps being a female professor in a
male-dominated field makes me particularly sensitive to this. To be
sure, most of my students are fine people who I respect and truly
enjoy teaching. But every once in a while I hear that little voice:
this one could just be mad enough to try to hurt me.

What happened at Virginia Tech doesn't raise a new fear for this
professor: it already exists, and tremours on par with what comes from
flying frequently. I thank the Virgina Tech faculty who took the time
to report their concerns about the gunman to the authorities. I
wonder whether we have the right balance between students' privacy and
community protection, as the current one leaves little room for
universities to legally respond to such warnings. I remind myself
that, periodic warnings from the voice notwithstanding, no student has
ever attempted to harm me physically. Statistics are on my side.

I don't know what the answer is, and frankly doubt there is one. I've
lived in states across the gun permissiveness scale, and working now
in gun-controlled Massachusetts hasn't quieted the little voice,
though it may dampen the tremours. Whether the real problem lies with
me, with increasing student pressures, with societal dysfunction, or
with availability of weapons is irrelevant. What does matter is
fostering communities that take time to notice and discuss potential
problems, continuing to debate how to balance security with the range
of non-dangerous human expression, and acknowledging that lack of
control and fear are, sadly, par for the course.

Should professors decriminalize copying?

An incident this weekend got me thinking again about plagiarism. As a professor, I've always been strict on detected plagiarism incidents in my courses (failure in the course if our judicial process finds the accused guilty). As a pragmatist, I believe there must be a better way to think about and handle this issue though. I appreciate arguments, such as Jason Johnson's recent Washington Post op-ed, that originality is not always the most important, or even most appropriate, criterion for a piece of work. Students naturally need to develop skills at synthesizing and interpreting material as well, which is the standard non-ethics argument against allowing attributed copying (Cognitive Daily has more discussion on Johnson's article). The latter argument counters the former with an expectation of interpretive work on _every_ assignment though. Perhaps that is asking too much.

Courses ask students to demonstrate a variety of skills. If a student shows solid skills at synthesizing and interpreting on several assignments then submits a largely copied assignment with attributions, has the student failed to satisfy the course goals? Shown a lack of integrity? Necessarily gotten less out of the assignment than a student who made practically no progress despite hours of effort? It isn't clear what this student would be guilty of beyond making a decision about resource allocation or time management. The student may have even gained something in searching for substitute work to turn in (though the web can make this too easy) and in deciding how to allocate work efforts that week.

Perhaps professors need to stop fighting the copying and make it acceptable (with attribution) right up there on the syllabus. Reframe copying as a lesson in risk and time management, rather than a crime. Set a grading rubric that allows students to copy sometimes, but with the expectation that they can explain and defend their choice of source. Deal harshly with lack of attribution. Hopefully, more students would provide the attribution since copying would carry no penalty. The time saved in not trying to enforce originality could be used to interview students submitting attributed work to confirm that they did understand it. That in turn could teach more about the tradeoffs of copying than lecturing ever could. It might take a bit more work on the professor's part to run these periodic spot checks, but they'd be far more rewarding than trudging through judicial procedures for plagiarism cases.

Marketing CS 101

A colleague pointed me to an essay entitled "The Death of Computing" over on the British Computer Society website (author: Neil McBride; dated: Jan 2007). The article offers several reasons for why CS enrollments will never return to their lofty heights of a few years ago. The main one (and the most compelling) is that the marketplace of students no longer finds CS necessary for creating computing technologies. Globalization and fears of low job prospects are mentioned as usual, but the overall message is on the market. The essay deride's universities' attempts to re-make the CS's image by focusing on games or fundamental connections to real-world problems to convince students that CS really is worth taking. It's an interesting read, in part for the vivid Titanic-esque imagery it uses to describe the situation.

It would be easy to respond defensively to this essay: the myth of job shortages has been debunked (thanks in parts to detailed studies such as the recent ACM report on offshoring) and everybody knows that computing has become a fundamental part of our intellectual infrastructure. But those arguments miss the point. Enrollments are about the student market, the student market is looking elsewhere, and universities are largely misinterpreting why. We talk about our "image problem" and look for the magic introductory course that will entice students to study CS. We reassure parents that the jobs aren't really gone. But what are we doing for the student who finds computing intriguing but is turned off by hours spent at a terminal building larger-scales systems? As the essay points out, technology has evolved to the point that casual system builders can achieve a lot, and without a CS degree. If academic CS hungers to rebuild its enrollments of the late 90s, it has to talk to these students. MIS programs aren't quite the right solution, because they focus on management rather than the creation of new technologies using computing. There's a fascinating open space here for us to fill (and if we don't, someone else will).

Of course, one could argue that enrollments aren't the right metric for academic CS, particularly in light of our infrastructural importance. Let's ask the physicists what they think. Like it or not, funding and academic clout are economic issues, and enrollments are a key factor. So let's embrace the challenge of thinking more broadly about what constitutes CS, damning the resource constraint issues for now. The question is thrilling. What would a computing program look like without hours of bleary-eyed coding in a lab? Do the folks emphasizing design and "computational X" have it right yet? My experience using modern computational products doubts it. Anyone else interested in this journey?