Additional profile information on Alfred Thompson at Google+
Right now I think we pretty obviously do. In the long run I think we'd be better off without them though. David Warlick asks a similar question in his blog and a companion poll. The way he asks it is “Are computer applications something that should be taught in a class, or something that should be learned by the students, independent of a class curriculum?“ (A summary of the comment discussion of his post may be found here and is worth reading.)
Kids today do figure out a lot of "computer stuff" on their own. They certainly could figure out a lot of the things we generally teach in computer applications courses. The problem is that they don't. I gave placement exams for a computer applications course for years and very few, perhaps 10%, of those who thought they "knew it all" actually knew enough to test out of the course.
I'll never forget overhearing one know it all tell a classmate "I wish I had known this stuff last year!" There is a lot that students generally do not learn on their own. In word processing few figure out automatically page numbering, headers and footers or footnoting. Doing it manually makes for quite a mess so you'd think they'd have incentive enough to learn it but for some reason few do. Perhaps it doesn't occur to them that it is possible.
In spreadsheets few students learn any but the most basic and simple of formulas. Graphing? Again generally only the most basic features. Almost no one learns databases. The one application kids do tend to learn a lot about is presentation software like PowerPoint. Even that is not all good though as they learn the features but not how to use them wisely. I've seen some feature rich presentations that fell apart on content and readability.
But to me having a special course in learning these applications is a waste of time. I believe that it is much better to teach these tools in some sort of context. Teach word processing features as they are needed in English so you can focus on concepts with the mechanics being secondary. For example use a word processor to teach outlining. Use the word processor to teach footnotes, end notes and bibliographies. Let the software handle the mechanics saving enough time for more repetition in different contexts.
Teach graphing in math courses and let the students use a spreadsheet to draw the graphs. Is it really useful for students to spend a half hour with a ruler and crayon to draw a bar graph and them spend another half hour taking the same numbers and putting them in a pie chart? Why not use the whole hour to show different kinds of data in different types of graphs? That way you can focus on the important concepts of picking the right sort of chart for the data. And you can spend time talking about why different graphs work and others do not and how the data matters.
Christy Tucker argues that a mix of integrated and separate is the way to teach computer applications and she has some good points. Her main point is that students should be given a solid base in a dedicated course but then what they learn must be integrated into the general curriculum. I don't disagree. I do think that the base should be taught as early as possible. Think reading.
In first grade reading is a specific subject. By second grade reading is a part of just about every subject. Long before high school reading is long gone as an independent course but students still learn new words and use reading in every course they take. That's the model we need to follow for computer applications.
Tricks are fun. It is often pretty satisfying to add a bit of code that is tricky, difficult or perhaps something that not everyone is going to understand. Well it's fun when it is done but later when the code has to be changed, modified, or worse - debugged its not always so much fun.
Tricks often work because they take advantage of ambiguity or implementation inconsistencies. or they rely on some deep understanding of low level details. The problem comes into play when those features change. For example a trick that takes advantage of overflows in a 16 bit word will break when the application moves to a 32 bit computer. Or a trick that takes advantage of a loop checking a value at the bottom even though the specification calls for it to be checked at the top of the loop will fail when a compiler that correctly implements the specification comes out. I actually know of cases where that latter problem happened!
There is a reason things are called tricks after all.
Tricks also make maintaining and debugging more difficult. Programmers really need to think about the person who will maintain their code. Most coding happens to existing code that someone else has written. If the next programmer doesn't know the trick they may very well have trouble working with your code.
Of course if you can't avoid using a trick at least comment it well. Explain it in detail so the next programmer to look at it will have a fighting chance to figure it out.
This is the fifteenth in a series of posts based on the book Programming Proverbs by Henry Ledgard. The index for the series is an earlier post and discussion of the list as a whole is taking place in the comments there. Comments on this "proverb" are of course very welcome here.
Among the beginning materials at the Beginner Developer Learning Center are the Bits & Bytes series of lessons. These lessons which can be read online or listened to as audio files (you can download both text and audio if you want) introduce some of the most basic and important concepts in computer science - no programming required.
I think these lessons would be good in a computer concepts/literacy course or as starters in a computer programming class. In fact they are probably good for someone who just wants a clue as to what this computer programming stuff is all about. Highly recommended.
[Note: Edited to correct links.]