Okay, so last time I suggested that even expert users have problems, because computers aren’t always predictable.
So, if we accept that computers will throw us for a loop occasionally, the issue becomes how we react to this. Blaming ourselves, falling prostrate before the almighty PC (or Mac, if you’re that way inclined 🙂 ) and begging that we be permitted to complete our terribly-important email is not going to cut it.
What is the alternative? Well, some take completely the opposite tack and assume the computer is entirely at fault, as it’s not doing exactly what they want it to, but I suspect that’s more related to ego; such people probably aren’t reading this, or aren’t going to take any notice of it. No, I suggest you imagine you are interacting not with a machine, but with a person.
This may not be all that difficult. People anthropomorphise objects all the time. Naming their car. Holding conversations with their pets. But that’s not what I’m talking about—you’re already doing that if you’re assuming the computer is smarter than you. Instead, recognise that the computer is just a machine following instructions, so when you’re using Microsoft Word (just as an example), you are navigating a bureaucratic maze defined by the person that created the program*.
Now, it’s quite reasonable to assume that this generic programmer you’re effectively interacting with is smarter than you. They certainly know more about computers. But only because they’re the combination of several brains. So how does this help? Because while you may not know much about programming a computer, you do know a lot about what it is you’re trying to do.
You see, every program is essentially a tool (or rather, a collection of tools, but lets keep it simple). A tool is designed to facilitate a particular task. If the person performing that task is finding the tool odd or frustrating, it’s probably because the way they think of the task is different to the way the tool designer thought of it.
For example, I have a ratchet screwdriver. It has a switch that enables it to be set to work clockwise (for tightening screws), counter-clockwise (for loosening screws), or both (acting like a standard screwdriver). One could conceivably add a fourth setting allowing the head to freely twist in both directions, but this isn’t of any use in practice. This is a silly example, but it’s the sort of thing that can happen with programs; a feature or setting is added (usually with the best of intentions) because it is easy to do, not because it is relevant or useful to the task.
If you don’t believe me, think of Clippy. And, when something goes wrong with your computer, ask yourself “does the programmer really understand what I’m trying to do?”.
* In general, it’s very unlikely a computer program was made entirely by one person. However, numerous decisions that went into its construction were made by people, and as you don’t know anything about them, you may as well assume a unified** Mr/Mrs Microsoft Word Programmer.
** If the team have been working together and communicating effectively, the program ought to feel consistent. If not, your generic programmer may come across as a bit… cuckoo.