Meta-ware
When I was a teenager, my computer-loving friends and I spent a lot of time using computer software, programming, collecting hundreds of files on dozens of 5.25" floppy disks, and tricking out our computers with third-party circuit boards and custom-installed switches.
As I entered my late teens, though, I began to notice a trend among my computer friends and the software programs they wrote and used. A trend I didn’t really like. In my head, I came up with a name for this trend: Meta-ware.
Meta-ware was any software that existed only to manipulate and/or organize other software — for example, a program that alphabetized all the files on a disk. Or a program that scanned the contents of all your floppies and created a library of them. Or a program that assisted your code-writing efforts with keyboard shortcuts and special formatting. I don’t even recall all the meta-ware that was in use then, but I remember that there was a lot of it.
And gradually, I decided that I didn’t want to write meta-ware. I didn’t even really want to use it much except when I felt it very necessary. To me, a computer is great for a few basic things:
Games and multimedia
Writing/communicating
Drawing/photo processing
Scientific simulations
Most of my teenage computer friends seemed to be into computers for the sake of computers. The whole environment of circuit boards, blinking characters on a screen, keyboards, floppies, files — they really liked all that, as a hobby. I think this is a large part of the reason why I’ve gravitated to Apple products. Apple really seems to get this, in a way that the Windows PC world doesn’t. Still today, my most savvy Windows PC friends don’t like Apple primarily because they can’t build a Mac from parts, or overclock its processor to get 10% better performance than their computer-nerd buddy. They want to do that stuff. Apple targets people who don’t want to do that — they just want to do things that you really need a computer to do.
In Apple’s early years I thought of Steve Wozniak as the genius behind the company, and I regarded Steve Jobs as little more than a tag-along promoter. My opinion of Jobs hit an all-time low when a friend told me that Jobs didn’t even write code at Apple!
Today my opinion has reoriented 180° — I now regard Woz as someone who was into computers for computers’ sake, who built computers to impress his techie buddies, and who was just in the right place at the right time to make a zillion. And I now see Jobs as the visionary who wanted computers to do something really enjoyable for all those people who had no interest in building a computer or writing code. Which of these two ways of seeing computers had a big future ahead of it? It’s pretty obvious today.
I spent my late teens and post-teen years trying to become a successful game programmer. While my late-teen friends were showing off their program to organize files or to reformat code, I was trying to write an actual game. And of course I found out that it’s a lot harder to write an interesting, playable game than it is to write a utility that performs some file manipulation. Even seemingly simple games turn out to be fiendishly complicated when you actually have to create one yourself and make it work right. Maybe that’s part of what meta-ware is all about: avoiding the monumental task of making a game, a word processor, or a photo editor, and instead writing something relatively simple that provides some techie-oriented enhancement to the computer-using experience.
In college I found that the professors had virtually zero interest in writing anything that anyone would really like to use, much less teaching us how to write such an app. All they wanted to teach was programming theory, style, and methodology. As a college student I spent enormous effort making sure that my code satisfied some professor’s idea of what good code should look like. But what did that code actually do? Usually, nothing much. Writing a program to create an alphabetized word-count list from a text file was about as real-world-functional as any of our assignments got. Because computer code is complicated, a whole world of coding theory has grown up around the practice. Sadly, the true purpose of computers is lost in this world — computers and coding have become an end unto themselves.
As students of this academic world graduate and move into the corporate environment, they carry this mentality forward with them. How many programmers and separate code modules does it take to make a payment on an insurance policy? You don’t even want to know. Imagine a single, stale peanut surrounded by fifteen layers of wrapping and packaging, and it comes with an inch-thick rulebook describing how each layer of packaging works and is to be manipulated. Really makes you yearn for a good old Snickers bar. Yes, a Snickers bar needs a wrapper — but look how super thin that wrapper is! And how immensely thick the chocolate bar inside! What happens when the wrapper designers go nuts and start thinking they’re making the real product? You get something like the “architecture astronauts” described by Joel Spolsky (here and here):
The Architecture Astronauts will say things like: “Can you imagine a [peer-to-peer] program like Napster where you can download anything, not just songs?” Then they’ll build applications like Groove that they think are more general than Napster, but which seem to have neglected that wee little feature that lets you type the name of a song and then listen to it — the feature we wanted in the first place. Talk about missing the point. If Napster wasn’t peer-to-peer but it did let you type the name of a song and then listen to it, it would have been just as popular.
When I embarked on my two-year, half-hour-a-day hobby of writing SWTSG, I knew it was to satisfy my hunger to write code that really does something. Code that isn’t much more complex than the task at hand, but is nevertheless very complex because the task is complex. An app that does something really well, without degenerating into a geek’s dream of pointless controls and customization options. “I should be able to make my crawl text magenta.” Um, no, you shouldn’t. If you really want to, change its hue in your movie-editing app. I’m not putting in a control for that. Put it in yourself if you want to; the sourcecode is available.
On the internet I see people making pronouncements of what good code must be. “No decent text-handing app doesn’t understand Unicode.” Really? How about this instead: “No decent character-set specification requires programmers to abandon virtually universal ASCII except when they need to.” I don’t actually know if Unicode satisfies that statement or not. And I shouldn’t need to know.
“No app should use any processor time when idle. If I find that an app uses processor when idle, I throw it in the trash right away.” Really? When you find a cool app that does something really neato, and does it really well, and doesn’t need to be left open for extended periods of time when idle, and doesn’t seem to be slowing down your computing experience even when left open idle — you use a special utility to find out that the app is using a trickle of processor, then you trash it and never use it again? I don’t know whether to feel sorry for you or conclude you must be lying. I myself have tolerated truly annoying bugs in software (e.g. Photoshop) because it was a great app and I wanted to use it. (Incidentally, SWTSG now uses zero processor when idle. I found the workaround and deployed it.)
While developing SWTSG, I post a simple question to a C forum: Why can’t I pass a 2-D, non-dynamically allocated array to a function? Or pass a 1-D, non-dynamically allocated array to a function by its name only (myArray instead of &myArray[0])? To which I get half a dozen quick replies in the vein of “Yes you can; what’s your problem?” or “You must post your entire sourcecode before we can properly attempt to answer your question.” Finally, one helpful poster says, “Oh yeah, you’re right. You can’t do that, and here’s the official C FAQ statement to that effect.” Then I realize that all those other condescending posters hadn’t even tried to do it before responding to my question, and apparently had never written a programming project that caused them to attempt it, either.
When did the theory of computing become more important than the meat of writing useful code and lots of it? Anyone can look at someone else’s code and find a dozen reasons to dismiss it as crap. And if they can’t immediately tell how the code works at a glance (as almost certainly will be the case with code that does something even moderately complicated) it’s easy for them to think it really is crap.
Code is like art, in that any critic can arbitrarily laud or lambast any work — but getting large numbers of people to use it is the real proof of its value.

