What follows is a rather meandering meditation.
Bah, techno-utopianism
There’s a lot of techno-utopianism coming out of Silicon Valley these days. Computers will do our bidding, we will all be free to pursue lives of leisure. Machines, amplifying human talent, will make sure we are all rewarded (or not) appropriately to our skills and effort.
You already know I’m skeptical. Technology today seems to take as often as it gives: you get slick, you give up control. You get free media, you are renting out your eyeballs. A lot of people seem to express powerlessness when it comes to computing.
And why shouldn’t they? They don’t control the OS on their phone, they don’t even know exactly what an OS is. They didn’t decide how Facebook should work. If they don’t like it, they can’t do much about it, except not use it — hardly an option in this world.
A better techno-utopianism
But I am a techno utopian in my own way. In my utopia, computers (and software) become flexible, capable building blocks and people understand them enough to put recompose them for their own purposes. These blocks would be honest, real, tools, that people — programmers and non-programmers — can wield skillfully and without a sense that there is anything hidden or subtle going on underneath the hood. Basically, that we’d all be masters of our technology. I’m not saying it’s realistic, it’s just my own preferred imaginary world.
How Dave Thinks of Computers
When I started my tech career, I was an engineer in the semiconductor business. We had computer aided design (CAD) software that helped us design chips. Logic simulators could help us test digital logic circuits. Circuit simulators could help with the analog stuff. Schematic capture tools let us draw circuits symbolically. Graphic layout tools let us draw the same circuits’ physical representation. Design rule checking tools helped us make sure our circuits conformed the manufacturing requirements. The list of CAD tools went on and on. And there was a thing about CAD tools: the were generally buggy and did not interoperate worth a damn. Two tools from the same vendor might talk, but from different vendors — forget it.
So we wrote a lot of software to slurp data from here, transform it in some way, and splat it to there. It was just what you had to do to get through the day. It was the glue that made a chip design “workflow” flow.
These glue tools were not works of software engineering art. They were hacks thrown together by skilled engineerins, but not skilled software engineers in order to get something done. The results were not handsome, not shrink-wrap ready, and not user-friendly, but were perfectly workable for our own purposes.
That experience really affected the way I view computing. To this day, I see people throw up their hands because Program X simply is incompatible with Program Y; the file formats are incompatible, undocumented, secret. Similarly, people who might write “just ok” software would never dream of trying because they do not have the time or knowledge to write Good, Proper Software.
In my utopia, that barrier would mostly go away.
The real key is knowing “how computers work.”
Khan!!!!
There is a push to teach “coding” in school these days, but I see it as simultaneously too much and too little. It’s too much in that the emphasis on learning to write software is going to be lost on many people who will never use that skill, and the knowledge of one programming language or another has a ridiculously short half-life. It is not important that every high school senior needs to be able to write an OS, or even a simple program. They do not need to understand how digital logic, or microprocessors work. And teaching them the latest framework seems pointless.
But I do want them to understand what data is, how it flows through a computer, the different ways it can be structured. When they ask a computer to do something, I want them to have a good, if vague notion of how much work that “thing” is.
That is, they should understand a computer, in the same way Kirk wants Savvis to know, “why things work on a starship.”
See, Kirk doesn’t understand warp theory or how impulse engines work, but he knows how a starship “works,” and that makes him a good captain.
How things work on a computer
Which brings me back to my utopia: I want everyone to know how things are done on a computer. Because anyone who has spent any length of time around computers knows that certain patterns emerge repeatedly — and a lot of programming has a constant vague feeling of deja-vu. That makes sense, because, more or less, computers really only do a few things (these overlap a lot, too):
- reading data from one (or more places) in memory, doing something with it, and writing the results to another (or more) places in memory.
- reading data from an external resource (file, network connection, usb port) or writing it to an (file, network connection, usb port, display, etc)
- waiting for something happen, then acting
With regard to data data itself, I want people do understand basic data structural concepts:
structs, queues, lists, stacks, hashes, files — what they are and why/when they are used. They should know that they can be composited arbitrarily: structs of hashes of stacks of files containing structs, etc.
And finally, I want people to understand something of computational complexity — what computer scientists sometimes refer to as “big-O” notation. Essentially, this is all about knowing how the difficulty of solving a problem grows with the size of the problem. It applies to the time (compute cycles) and space (memory) needed to solve a problem. Mastering this is an advanced topic in CS education, which is why it is usually introduced late-ish in CS curricula. But I’m not talking about mastery. I’m talking about awareness. Bring it in early-ish, in everyone’s curriculum!
Dave’s techno-utopia
Back to my utopia. In my utopia, computers, the Internet would not be the least bit mysterious. People would have a gut-level understanding of how it works. For example, what happens when you click search in Google.
Anyone could slap together solutions to problems using building blocks that they may or may not understand individually, but whose purpose and capabilities they do understand, using the concepts mentioned above. And if they can’t or won’t do that, at least they can articulate what they want in those terms.
In Dave’s techno utopia, people would use all kinds of software: open, proprietary, big and small, that does clever and exotic things that they might never understand. But they would also know that, under the hood, that software slurps, transforms, and splats, just like every other piece of software. Moreover, they would know how to splat and slurp from it themselves, putting together “flows” that serve their purposes.