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.
Showing posts with label computing. Show all posts
Showing posts with label computing. Show all posts
Monday, October 7, 2013
Saturday, September 21, 2013
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.
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.
Sunday, November 4, 2007
All in my head
Blustery weather yesterday after a hectic week propelled me to do something I haven't done in years: read a book start to finish in a single day. I picked up Louann Brizendine's "The Female Brain" some weeks ago, intending to save it for travel reading. My fried brain was drawn to the subject yesterday, however, rewarding me with an eye-opening, unsettling, and thought-provoking afternoon.
Brizendine is a neuropsychiastrist with expertise and clinical practice on interactions between hormones and mood. The book explains the interaction between hormones and brain operation in women, with contrasting references to these interactions in men. Chapters cover the various stages of women's hormonal transitions, from birth, childhood, puberty, early adulthood, parenting, middle adulthood, and menopause. Each chapter explains the hormones and hormonal cycles that are most active within each of theses phases; these are related to brain functionality and how this predisposes women to pay attention to different issues at different phases of life and periods within the hormonal cycle. It's engaging and informative, with extensive citations and reference notes.
Brizendine wants women to understand how hormones influence brain function so they can anticipate and plan behavior accordingly. Knowing that we are hormonally predisposed to being more attuned to the needs of others in the first two weeks of our cycles, for example, may help women evaluate requests to take on additional tasks during this time (is this how I get talked into more committee work?). Understanding how hormone phases reduce our pleasure or anger responses may help us maintain stronger relationships, especially when the contrast to men's hormone and brain functions is clear.
The book was eye-opening because I didn't know about the hormonal phases over a lifetime, or much about how particular hormones predisposed me to certain responses. Looking back over my life for the last several weeks, the info presented in this book could explain a lot. And that's precisely what I found unsettling about it: it was too easy to agree with the findings she reports, too easy to wave a flag of womenhood and proclaim that "my hormones made me do it, and differently than he would have" (for appropriate values of he). Brizendine is well-aware of this potential and emphasizes the complementing role of nurture and our ability to choose how to react to biologically-motivated impulses. Any fault of overeager application of this book would be my fault, not hers.
But on some level, I do want to believe that the findings of these studies are valid. How wonderful to narrow the range of my influence in how I react as I defend my differences from the plethora of males around me. Responsibility is great, in moderation. And it's nice to have a readable reference that my reactions both are and are not "all in my head". I want to jump for relief having read this, yet bounce instead from the (appropriate) brakes of my scientific training. I also wanted a home-hormone test kit, so I could try mapping the results against my own moods and responses over time.
My most thought-provoking moment came in the section on puberty, discussing how girls in this stage become intensely focused on social bonding in contrast to boys who retreat. Against the imagery of girls obsessed with social connection and position, computing and science don't stand a chance as currently presented. If we truly want more women in these fields, we have to question something, whether it's how we expose pre-college students to these subjects or how we get students to stop selecting away from certain topics too early in life. I wonder whether those of us who did make it to college majors in these areas had different hormonal ratios than our female peers. Timing may be more problematic than we, or at least I, thought in thinking about how to make these fields more inviting to young women.
Brizendine is a neuropsychiastrist with expertise and clinical practice on interactions between hormones and mood. The book explains the interaction between hormones and brain operation in women, with contrasting references to these interactions in men. Chapters cover the various stages of women's hormonal transitions, from birth, childhood, puberty, early adulthood, parenting, middle adulthood, and menopause. Each chapter explains the hormones and hormonal cycles that are most active within each of theses phases; these are related to brain functionality and how this predisposes women to pay attention to different issues at different phases of life and periods within the hormonal cycle. It's engaging and informative, with extensive citations and reference notes.
Brizendine wants women to understand how hormones influence brain function so they can anticipate and plan behavior accordingly. Knowing that we are hormonally predisposed to being more attuned to the needs of others in the first two weeks of our cycles, for example, may help women evaluate requests to take on additional tasks during this time (is this how I get talked into more committee work?). Understanding how hormone phases reduce our pleasure or anger responses may help us maintain stronger relationships, especially when the contrast to men's hormone and brain functions is clear.
The book was eye-opening because I didn't know about the hormonal phases over a lifetime, or much about how particular hormones predisposed me to certain responses. Looking back over my life for the last several weeks, the info presented in this book could explain a lot. And that's precisely what I found unsettling about it: it was too easy to agree with the findings she reports, too easy to wave a flag of womenhood and proclaim that "my hormones made me do it, and differently than he would have" (for appropriate values of he). Brizendine is well-aware of this potential and emphasizes the complementing role of nurture and our ability to choose how to react to biologically-motivated impulses. Any fault of overeager application of this book would be my fault, not hers.
But on some level, I do want to believe that the findings of these studies are valid. How wonderful to narrow the range of my influence in how I react as I defend my differences from the plethora of males around me. Responsibility is great, in moderation. And it's nice to have a readable reference that my reactions both are and are not "all in my head". I want to jump for relief having read this, yet bounce instead from the (appropriate) brakes of my scientific training. I also wanted a home-hormone test kit, so I could try mapping the results against my own moods and responses over time.
My most thought-provoking moment came in the section on puberty, discussing how girls in this stage become intensely focused on social bonding in contrast to boys who retreat. Against the imagery of girls obsessed with social connection and position, computing and science don't stand a chance as currently presented. If we truly want more women in these fields, we have to question something, whether it's how we expose pre-college students to these subjects or how we get students to stop selecting away from certain topics too early in life. I wonder whether those of us who did make it to college majors in these areas had different hormonal ratios than our female peers. Timing may be more problematic than we, or at least I, thought in thinking about how to make these fields more inviting to young women.
Wednesday, October 17, 2007
Mental accounting
While paying a stack of bills this morning, I noticed a new online payment option for one of our annual bills. With all the sabbatical travel we did last year, online bill pay and tracking was a lifesaver: I put monthly reminders into my calendar to login and pay our credit cards, billed the utilities directly, and didn't worry at all about missing payments while on the road. I had the checkbook in hand to pay today's annual bill the old-fashioned way, but decided to check out the ebilling option.
To my surprise, I paid the bill the old-fashioned way anyway. Signing up for ebilling meant another account and another password, and I have spent far too much time this week trying to remember various usernames and passwords for rarely-accessed sites. The website design rendered poorly on firefox, so the instructions were hard to read. Worst of all, the signup page stated that once you signed up for ebilling, you would no longer receive paper statements. You could get paper statements again at any time by calling customer service, who would then unenroll you from electronic bill paying. In other words, it appears that you can only pay your bill online if you agree to stop receiving paper statements.
The loss of a paper bill was the final straw for me. For annual bills, a piece of paper on my desk to remind me to make a payment is essential. Monthly bills are routine enough that my mental cycle checks in if I haven't issued a payment recently, but annual bills are hopeless. The volume of email I get mandates the use of email filters, and I sometimes ignore the non-essential filters for days or weeks at a stretch. At core, I simply don't trust my personal information management setup--ie, the combination of my calendar and email--to remind me about critical issues that only happen once a year. Out of sight, out of mind feels like a very real danger where annual bills are concerned. Something is clearly not working quite right when we choose not to use tools that supposedly save time and memory out of a fear that we might not remind ourselves to use them.
To my surprise, I paid the bill the old-fashioned way anyway. Signing up for ebilling meant another account and another password, and I have spent far too much time this week trying to remember various usernames and passwords for rarely-accessed sites. The website design rendered poorly on firefox, so the instructions were hard to read. Worst of all, the signup page stated that once you signed up for ebilling, you would no longer receive paper statements. You could get paper statements again at any time by calling customer service, who would then unenroll you from electronic bill paying. In other words, it appears that you can only pay your bill online if you agree to stop receiving paper statements.
The loss of a paper bill was the final straw for me. For annual bills, a piece of paper on my desk to remind me to make a payment is essential. Monthly bills are routine enough that my mental cycle checks in if I haven't issued a payment recently, but annual bills are hopeless. The volume of email I get mandates the use of email filters, and I sometimes ignore the non-essential filters for days or weeks at a stretch. At core, I simply don't trust my personal information management setup--ie, the combination of my calendar and email--to remind me about critical issues that only happen once a year. Out of sight, out of mind feels like a very real danger where annual bills are concerned. Something is clearly not working quite right when we choose not to use tools that supposedly save time and memory out of a fear that we might not remind ourselves to use them.
Sunday, July 1, 2007
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?
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?
Friday, June 8, 2007
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.
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.
Thursday, June 7, 2007
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?
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?
A usability nightmare
A truly dreadful user-interface experience yesterday called for posting, but Shriram got to it first and included my angle so I'll just include a link to his post instead. Admittedly, I've been reading about usability a lot lately so I'm more conscious of such issues, but this application really is an affront to software design (and being used for a software engineering conference, no less!).
Tuesday, May 29, 2007
Computational doping, part 2
My sister responded to my first computational doping post with a link to a NYTimes article (subscription reqd) from a couple of weeks ago about an amputee with prosthetic legs who wants to compete in Olympic track. The jury is still out on whether he will be allowed to compete, with one of the major questions being whether his prosthetics give him an unfair competitive advantage.
This got me thinking about my memory software again. My description in the first post said nothing about the intended interface between me and the software. I've generally envisioned a standard sort of interface with menus and links to click as I actively navigate this auxiliary memory. This interface would require so much active use on my part that I'd never really use the software. I want this auxiliary memory to operate without my having to direct it all the time. One such interface would be a brain prosthetic that tapped into my existing thought process and augmented my technical information management, like in the ongoing research into using brain signals to control prosthetic limbs
And now I bet the Turing award committee gets uncomfortable, even if the wearer developed the interface and the software (a fairly formidable research challenge that might well be deserving of the award in and of itself). How does a change of interface make this much difference? Using the first system still required substantial work on the part of the researcher (to initiate use of the system). The second system works subconsciously. It saves effort on the part of the user. Once the user no longer has to actively work as hard, the results feel less worthy of recognition. The work matters as as much as the result. The ends don't compensate for the means.
So perhaps the perception of work is what leads us to view some forms of advantage as unfair. Doping works passively. Training in wind tunnels requires action and dedication. Prosthetic limbs (are perceived to, at least) work without active behavior by the wearer. It's the good old work ethic again. That's an American interpretation, at least. We want work to count for something (students often plead for a higher grade based on effort). But that doesn't explain our acceptance of altitude tents for athletes (which at least require some inconvenience of loss of comfort compared to a hotel bed). There, the distinction with doping appears to be whether we violate the body for advantage. A prosthetic auxiliary brain might also violate us physically (if nerve probes had to be implanted rather than worn on the surface). I somehow suspect that even surface probes to access an artificial brain would make some people uncomfortable with rewarding the results, though.
Doping makes me uncomfortable because it might effectively demand an athlete to violate their body to be able to compete. A breakthrough in prosthetic memory research could do the same to scientists. Much excellent research still arises from human perception and inspiration, so the human scientist still has a tremendous role to play in creating results. Athletes similar have instincts of when to hang back, when to attack, and how to read a competitor. It would be interesting to see studies of these more perceptual skills in elite athletes, and how much they correlate with winning performances.
This got me thinking about my memory software again. My description in the first post said nothing about the intended interface between me and the software. I've generally envisioned a standard sort of interface with menus and links to click as I actively navigate this auxiliary memory. This interface would require so much active use on my part that I'd never really use the software. I want this auxiliary memory to operate without my having to direct it all the time. One such interface would be a brain prosthetic that tapped into my existing thought process and augmented my technical information management, like in the ongoing research into using brain signals to control prosthetic limbs
And now I bet the Turing award committee gets uncomfortable, even if the wearer developed the interface and the software (a fairly formidable research challenge that might well be deserving of the award in and of itself). How does a change of interface make this much difference? Using the first system still required substantial work on the part of the researcher (to initiate use of the system). The second system works subconsciously. It saves effort on the part of the user. Once the user no longer has to actively work as hard, the results feel less worthy of recognition. The work matters as as much as the result. The ends don't compensate for the means.
So perhaps the perception of work is what leads us to view some forms of advantage as unfair. Doping works passively. Training in wind tunnels requires action and dedication. Prosthetic limbs (are perceived to, at least) work without active behavior by the wearer. It's the good old work ethic again. That's an American interpretation, at least. We want work to count for something (students often plead for a higher grade based on effort). But that doesn't explain our acceptance of altitude tents for athletes (which at least require some inconvenience of loss of comfort compared to a hotel bed). There, the distinction with doping appears to be whether we violate the body for advantage. A prosthetic auxiliary brain might also violate us physically (if nerve probes had to be implanted rather than worn on the surface). I somehow suspect that even surface probes to access an artificial brain would make some people uncomfortable with rewarding the results, though.
Doping makes me uncomfortable because it might effectively demand an athlete to violate their body to be able to compete. A breakthrough in prosthetic memory research could do the same to scientists. Much excellent research still arises from human perception and inspiration, so the human scientist still has a tremendous role to play in creating results. Athletes similar have instincts of when to hang back, when to attack, and how to read a competitor. It would be interesting to see studies of these more perceptual skills in elite athletes, and how much they correlate with winning performances.
Monday, May 28, 2007
Computational doping
As a fan of road cycling, I've been following the Floyd Landis trial and recent doping revelations (mostly via velonews). The whole affair feels a bit like a witch-hunt at a wizarding convention, in that doping sounds sufficiently commom back in the late 90s that lots of riders probably could make confessions. The question remains whether they will be burned at the stake fueled by collective desire to do something about this practice now.
At the same time, getting into a new research project reawakened my envy at my husband's memory for research results. He's very good at recalling the gists of projects, who worked on them, and how they relate to other projects. He builds mental roadmaps of research areas in his head as he reads, and can recall and access those models easily. My memory is far better for birthdays and people's stories, which isn't usually as useful for professional computer science.
As this skill I desire is all about managing information, though, I should be able to imagine a software system to help me build, manage, and access a store of professional knowledge. The technical challenges to this notwithstanding, I found myself pond ring whether using such a tool would be analogous to doping in sport.
There are clearly some similarities: person uses artificial substance to enhance their ability to perform; person may get more money and more prestige as a result of better performance; person isn't competing solely on their natural talents. There are also some strong differences: sport has one winner (individual or team) whereas research competition usually has several; elite sporting is more financially lucrative than elite research; the public gets emotionally caught up in sport.
High-profile awards such as a Nobel or a Turing (the analogue for computer science) are exceptional in having single winners and non-trivial financial rewards (though not sport level). Imagine a Turing-award winner attributing success partly to a program used to help manage idea infrastructure. The awardee would probably get bonus points for having written the program, but even if someone else wrote it, I can't imagine the computing press calling to revoke the reward.
Is this because what prompts a research award is the ideas instead of the person (the person gets credit, but the idea is what captures the imagination). The same emotion arises in sport: I don't want to let the doping allegations taint Floyd's stage 17 ride in the 2006 Tour de France because it was so frigging _beautiful_. I love cycling for those moments of explosive power where the person disappears and only an instrument highly tuned to its environment, internal condition, and condition of its competitors remains. At that moment, I don't care whether the riders are aided by technology: the joy is my drug, and I just want to experience it.
But when the ride is over and the podium gone, doping takes us past the performance and focuses on the person. One standard argument against doping is that it is unfair, disadvantaging those who choose not to dope. The usual counterargument is that doping can help some riders be more competitive with those with more natural abilities. My memory-enhancing software would fall into the latter, but an already top person could use the same software to widen the gap again. Unlike drugs, my software would cause me no physical harm. In an ideal world, nobody would have to choose between winning and harming themselves, but winning often requires risk and compromise. How is sport truly different?
In the end, research and sport have different value systems, different notions of what makes a heroic performance. Both value results. In research, purity of results comes from replicability; collaboration is both welcome and expected to be visible (via attribution and citation). In individual sport, purity manifests as an unaided athlete achieving the improbable. Collaboration is rampant (top cyclists use a myriad of bike designers, clothing designers, wind tunnel simulations, etc), but expected to be invisible. Doping destroys invisibility and becomes an affront to purity. If our culture viewed scientists as heroes on par with athletes, would my software become distasteful? I suspect not, because we still view research as "hard" and athletics as inborn. If our athletes are simply trying to live up to our expectations of them, perhaps we need to ask whether it is us, not them, who are really on drugs.
At the same time, getting into a new research project reawakened my envy at my husband's memory for research results. He's very good at recalling the gists of projects, who worked on them, and how they relate to other projects. He builds mental roadmaps of research areas in his head as he reads, and can recall and access those models easily. My memory is far better for birthdays and people's stories, which isn't usually as useful for professional computer science.
As this skill I desire is all about managing information, though, I should be able to imagine a software system to help me build, manage, and access a store of professional knowledge. The technical challenges to this notwithstanding, I found myself pond ring whether using such a tool would be analogous to doping in sport.
There are clearly some similarities: person uses artificial substance to enhance their ability to perform; person may get more money and more prestige as a result of better performance; person isn't competing solely on their natural talents. There are also some strong differences: sport has one winner (individual or team) whereas research competition usually has several; elite sporting is more financially lucrative than elite research; the public gets emotionally caught up in sport.
High-profile awards such as a Nobel or a Turing (the analogue for computer science) are exceptional in having single winners and non-trivial financial rewards (though not sport level). Imagine a Turing-award winner attributing success partly to a program used to help manage idea infrastructure. The awardee would probably get bonus points for having written the program, but even if someone else wrote it, I can't imagine the computing press calling to revoke the reward.
Is this because what prompts a research award is the ideas instead of the person (the person gets credit, but the idea is what captures the imagination). The same emotion arises in sport: I don't want to let the doping allegations taint Floyd's stage 17 ride in the 2006 Tour de France because it was so frigging _beautiful_. I love cycling for those moments of explosive power where the person disappears and only an instrument highly tuned to its environment, internal condition, and condition of its competitors remains. At that moment, I don't care whether the riders are aided by technology: the joy is my drug, and I just want to experience it.
But when the ride is over and the podium gone, doping takes us past the performance and focuses on the person. One standard argument against doping is that it is unfair, disadvantaging those who choose not to dope. The usual counterargument is that doping can help some riders be more competitive with those with more natural abilities. My memory-enhancing software would fall into the latter, but an already top person could use the same software to widen the gap again. Unlike drugs, my software would cause me no physical harm. In an ideal world, nobody would have to choose between winning and harming themselves, but winning often requires risk and compromise. How is sport truly different?
In the end, research and sport have different value systems, different notions of what makes a heroic performance. Both value results. In research, purity of results comes from replicability; collaboration is both welcome and expected to be visible (via attribution and citation). In individual sport, purity manifests as an unaided athlete achieving the improbable. Collaboration is rampant (top cyclists use a myriad of bike designers, clothing designers, wind tunnel simulations, etc), but expected to be invisible. Doping destroys invisibility and becomes an affront to purity. If our culture viewed scientists as heroes on par with athletes, would my software become distasteful? I suspect not, because we still view research as "hard" and athletics as inborn. If our athletes are simply trying to live up to our expectations of them, perhaps we need to ask whether it is us, not them, who are really on drugs.
Subscribe to:
Posts (Atom)