Learning to use the system
Learning to use the system
From Talking About Machines by Julian Orr, page 48:
These same users, however, cannot be bothered to learn how they are supposed to use the machines. They claim they do not have time, he says. They seem to have plenty of time to stand around and bitch, though. [...] He finds this very frustrating, and the customers do not respond to his frustration.
In context, a technician is frustrated that he is constantly having to fix problems caused by the users' improper use of the machines he maintains. If the users learned how to use the machines properly, which they refuse to do, the machines wouldn't be broken so often.
I share both the technician's irritation and the user's reluctance to learn: The limitation is probably not time but some mix of learned helplessness (believing that it's too difficult) and managerial unwilling to budget time and money for the training needed. On the other hand, the users could certainly stand to acquire some adjacent skills to make the technician's life easier. Every time you encounter a problem it's worth asking the person responsible for fixing it a little bit about what caused it and what you could have done to avoid that. A lot of the time you'll forget or not be able to implement the answer, but over time you might pick up enough by osmosis to make both of your lives better.
On the other hand, the technician is probably underestimating just how hard it is to use the system without breaking it. People are operant conditioned by the systems they use into using them in a way that mostly doesn't break, and experts are the ones who have experienced the most of this, so probably experience the system very differently than the users do.
But even experience users sometimes still seem to use the system in ways that break it. I think part of what's going on here is that operant conditioning only works when you have the ability to learn, and many people never acquire enough of a working model of the system to be able to learn. If you don't know what it was you did that caused the bad result, how can you learn to avoid that? (This is why it's important to ask questions).
If we want to learn to use a system, part of that is speeding up this process of operant conditioning - learning what's safe, and what to avoid. Having an adequate mental model of the system seems to be a key part of that, because it lets you figure out this mapping of action to outcome.
I notice this a lot with git. There's a really huge difference in how people experience git, and it seems to largely come down to whether they have a good working model of it. git is a horrible mess of weird multipurpose arbitrary commands, and it has a number of sharp edges, but honestly for me it's basically fine and it causes me almost no problems, and it has been like that almost from day one, because I roughly know how it works and so can think of things in terms of what I'm trying to achieve in the underlying model. Without that model, you only see the external complexity, which is almost impossible to navigate.
Another place I've seen this is mathematics education. People try to teach maths as a bunch of facts that you have to memorise. This is basically impossible and nobody will ever learn to be a mathematician that way - they will either learn to be a mathematician on their own, they will brute force their way through some exams and then forget everything, or they will fail horribly, because without an underlying understanding of the nature of mathematics and how everything fits together it's just an unreasonable amount of pointless rules and facts to memorise and you will experience all of it as arbitrary.
People often seem very resistant to acquiring models of the systems they use, because that seems hard and time consuming, but the reality is that trying to use a system without some sort of model of it is much harder and will be a source of constant and bewildering suffering.