Computing at odds with getting Faster

I just finished reading James Gleick’s book Faster: The Acceleration of Just About Everything.  It’s a 10 year old book now, but the story is still valid today.  I didn’t enjoy it as much as his books Chaos or Genius. However, the points of Faster are particularly relevant for computing education.

One of Gleick’s anecdotes was on how AT&T sold Touch Tone dialing in 1964 as saving an average of ten seconds per seven-digit number dialed.  Now, we have speed dialing.

In the post-Touch Tone generation, you probably have speed-dial buttons on your telephone.  Investing a half-hour in learning to program them is like advancing a hundred dollars to buy a year’s supply of light at a penny discount…To save time, you must invest time.

Do some students and end-user programmers invest time in learning to program to “advance a hundred dollars to buy a year’s supply of light at a penny discount”?  Are they looking to program in order to save time, to do things faster and more efficiently?  Do they give up on learning to program when they realize that it doesn’t work that way?

The problem is that I don’t think that ever really happens for the individual writing code for him or herself.  It’s hard to program.  The time cost of programming amortizes over users.  The development cost of Microsoft Office, amortized over millions of users, results in a profit for Microsoft.  A few hours of a programmer’s time on some feature of Excel enables many hours of use of that feature by many users.  But for any individual writing code for him or herself?  Takes a lot more than 30 minutes of programming software to get the same usefulness of 30 minutes of programming speed-deal buttons.

So why program?  In the Media Computation Python CS1 class, we tell students that they should program in order to create a replicable process (if you need something to be done the same way, maybe by others, many times), to create a process that many people can use (like when commercial software is created), or to communicate a process (like when trying to explain a theory of how something dynamic happens, like DNA transcription or evolution).  Paul Graham tells us that hackers write software to create beauty.  But few people successfully program in order to save time for themselves — you’d have to do something many times to make the benefits of use outweigh the cost of development.

Maybe it shouldn’t be that way.  Maybe software development should be easier.  I wonder if you could make it easier, and still keep all the fun, all the communicative power of programing languages, all the “Passion, Beauty, Joy, and Awe“?

The overall story of Faster may be relevant for understanding the decline in interest in computer science.  Gleick claims that “boredom” is actually a modern word and concept.  “To bore meant, at first, something another person could do to you, specifically by speaking too long, too rudely, and too irrelevantly.”  Today, we are bored by simple silence — by not enough challenges, not enough multi-tasking, by too many choices.  We have so many options for entertainment that we choose many at once, so that we drive, while listening to the radio, and talking on the cell phone (not texting or doing email, of course).  Gleick (naturally, as an author) bemoans the death of the book, because readers are too easily bored to pay attention to a whole book, and always have the options of magazines or blogs or just 140 character “tweets.”  Why would anyone make a career choice like “computer science” when there are so many other choices that are less boring, take less concentrated focus, take less time?

Gleick provides an afterword for the electronic version of the book (I read it on my Kindle), where he speaks to some of these concerns:

I believed when I began Faster, and believe now more than ever, that we are reckless in closing our eyes to the acceleration of our world. We think we know this stuff, and we fail to see connections. We struggle to perceive the process of change even as we ourselves are changing.

Tags: image of computing, image of computer science

Powered by Qumana

How to help professional teachers share their practice

Reminds me of Josh Tenenberg’s and Sally Fincher’s Disciplinary Commons and our own Disciplinary Commons for Computing Educators.  There’s a real challenge in sharing our teaching practices, making them consistent (where useful, like for grading in this piece), and measuring teaching practices to determine effectiveness.  We know that teaching is really important, but we don’t have good ways of defining, showing, and teaching what makes for effective computing teaching.

A student taking an oral examination can be filmed and their performance ‘marked’ with written, sound or visual comments using a multimedia tool called LimSee3. The resulting multimedia document can be shared so that other teachers and examiners can develop consistent approaches to marking.

This innovative tool is just one of a series developed during the Europe-wide Palette project to help ‘communities of practice’, such as teachers. Communities of practice are disparate groups of people – usually professionals – who strive to define, shape, share and manage a body of knowledge.

via ICT Results – Re-learning how to help professionals share their practice.