I upvoted this comment, but I want to add an important caveat. Whether, and how much, you trust your own judgment over that of an expert should depend at least in part on the degree to which you think your situation is unusual.
The IT guy wants you to shut up and go away, but (if in fact he is an expert and not a trained monkey reading a script) he’s not going to spout random nonsense at you just to get you to leave. He’s going to tell you things relevant to what is, in his experience, the usual situation.
Consider well whether you’re sure your problem is some special snowflake. The IT guy has seen a lot of issues. Sometimes he can, before you finish your first sentence, know exactly what your problem is and how to fix it, and if he sounds bored when he tells you “just reboot it”, that doesn’t mean that he’s wrong. If it costs you little, try his advice first.
Whether, and how much, you trust your own judgment over that of an expert should depend at least in part on the degree to which you think your situation is unusual.
The expert also is better equipped to discern whether a situation is unusual, because the expert has seen more.
To the non-expert, something really mysterious and weird must be going on to explain these puzzling symptoms. Computer A can ping computer B, but B can’t ping A? That’s so strange! After all, ping is supposed to test whether two computers can talk to each other on the network, right? How could it possibly work one way but not the other? Is something wrong with the switch? Is one of the network cards broken? Is it a virus?!
To the expert, that’s not unusual at all. One computer has the wrong subnet mask set. Almost every time. Like, that’s 20 to 100 times more likely than a hardware problem or something broken in the network infrastructure, and it can be checked in seconds. And while the machine may have a virus too, that’s not what causes these symptoms.
The expert also is better equipped to discern whether a situation is unusual, because the expert has seen more.
Very true as well, though I will add the counter-caveat that the expert is usually biased toward concluding that your situation is not unusual. This is why many “tech support horror stories” have a bit where the narrator goes ”… and then, when they finally got it through their heads that yes, I had tried restarting it five times, and no, I didn’t have the wrong settings …”
I suspect there are a couple of things going on there.
One, it’s important to distinguish consulting an expert from consulting a tech support script. Most of the time when you call up tech support, you’re talking to a human being, but not an expert. You’re talking to a person whose job it is to execute a script in order to relieve the experts from dealing with the common cases.
(And yes, it’s in the interest of a consumer tech-support department to spend as little money on expensive experts as they can get away with — which is why when a Windows box has gotten laggy, they say “reboot it” and not “pop open the task manager and see what’s using 100% of your CPU”. They don’t want to diagnose the long-term problem (your Scrabble game that you left running in the background has a bug that makes it busy-wait if it’s back there for 26 hours); they want to make your computer work now and get you off the line. That’s a different case from, for instance, an institutional IT department (at, say, a university) that has to maintain a passable reputation with the faculty who actually care about getting their research done.)
Two, there’s narrative bias. The much-more-numerous cases where the simple fix works don’t make for good “horror stories”, so you don’t hear them retold. Especially the ones where the poor user is now embarrassed because they have to admit they were outguessed by a tech-support script after giving the support tech a hard time.
(Yeah, I like good tech support too; that’s part of why I use the local awesome option (Sonic.net) for my ISP instead of Comcast. I can call them up and talk to someone who actually knows what ARP means. But sometimes the problem does go away for months when you power-cycle the damn modem.)
Very true as well, though I will add the counter-caveat that the expert is usually biased toward concluding that your situation is not unusual.
Well, we don’t know that they’re actually biased in this direction until we know how their assessment of the probability that the usual thing is going on compares to the actual probability that the usual thing is going on.
Yes, there are plenty of “tech support horror stories” where the consultant has a hard time catching on to the fact that the complainant is not dealing with a usual or trivial problem, but for every one of those, there tends to be a slew of horror stories from the other end, of people getting completely wound up over something that the consultant can solve trivially, and failing to follow the simple advice needed to do so.
The consultants could be very well calibrated, and still occasionally be dramatically wrong. Beware availability bias.
Note that cases where the tech tells you that it’s usual problem X, and you deny this, asserting that your thing is a special snowflake, is NOT a case of the opposite bias. It’s just a case of correct identification.
The opposite bias would be if the usual thing was going on, but the tech thought that it was some unusual thing.
Other IT-experienced people are welcome to correct me on this, but in my experience, the latter almost never happens, and when it does, it’s mostly with newbie techies, recent hires/trainees, etc.
This makes it substantially more likely that tech people have “usual problem bias” than that they have “unusual problem bias”, and that they are well-calibrated. The usual problem bias could be small or it could be large, but available evidence is fairly clear that it exists.
The point I was making was not that tech support is likely to have an “unusual problem bias,” but that being correctly calibrated with respect to usual and unusual problems will tend to appear like a “usual problem bias” when you examine in isolation the cases where they’re wrong, because you would tend to observe cases where they need a significant amount of evidence to persuade them of the presence of an unusual problem, but not an unusual one.
If you examine cases where they’re right, you may find a large number of cases where the customer insists that the problem is not addressed by the tech support’s script, only to be proven wrong; these often appear in the horror stories posted by tech support. Thus, tech support may to some extent be rationally discounting evidence favoring unusual problems.
I upvoted this comment, but I want to add an important caveat. Whether, and how much, you trust your own judgment over that of an expert should depend at least in part on the degree to which you think your situation is unusual.
The IT guy wants you to shut up and go away, but (if in fact he is an expert and not a trained monkey reading a script) he’s not going to spout random nonsense at you just to get you to leave. He’s going to tell you things relevant to what is, in his experience, the usual situation.
Consider well whether you’re sure your problem is some special snowflake. The IT guy has seen a lot of issues. Sometimes he can, before you finish your first sentence, know exactly what your problem is and how to fix it, and if he sounds bored when he tells you “just reboot it”, that doesn’t mean that he’s wrong. If it costs you little, try his advice first.
The expert also is better equipped to discern whether a situation is unusual, because the expert has seen more.
To the non-expert, something really mysterious and weird must be going on to explain these puzzling symptoms. Computer A can ping computer B, but B can’t ping A? That’s so strange! After all, ping is supposed to test whether two computers can talk to each other on the network, right? How could it possibly work one way but not the other? Is something wrong with the switch? Is one of the network cards broken? Is it a virus?!
To the expert, that’s not unusual at all. One computer has the wrong subnet mask set. Almost every time. Like, that’s 20 to 100 times more likely than a hardware problem or something broken in the network infrastructure, and it can be checked in seconds. And while the machine may have a virus too, that’s not what causes these symptoms.
Very true as well, though I will add the counter-caveat that the expert is usually biased toward concluding that your situation is not unusual. This is why many “tech support horror stories” have a bit where the narrator goes ”… and then, when they finally got it through their heads that yes, I had tried restarting it five times, and no, I didn’t have the wrong settings …”
I suspect there are a couple of things going on there.
One, it’s important to distinguish consulting an expert from consulting a tech support script. Most of the time when you call up tech support, you’re talking to a human being, but not an expert. You’re talking to a person whose job it is to execute a script in order to relieve the experts from dealing with the common cases.
(And yes, it’s in the interest of a consumer tech-support department to spend as little money on expensive experts as they can get away with — which is why when a Windows box has gotten laggy, they say “reboot it” and not “pop open the task manager and see what’s using 100% of your CPU”. They don’t want to diagnose the long-term problem (your Scrabble game that you left running in the background has a bug that makes it busy-wait if it’s back there for 26 hours); they want to make your computer work now and get you off the line. That’s a different case from, for instance, an institutional IT department (at, say, a university) that has to maintain a passable reputation with the faculty who actually care about getting their research done.)
Two, there’s narrative bias. The much-more-numerous cases where the simple fix works don’t make for good “horror stories”, so you don’t hear them retold. Especially the ones where the poor user is now embarrassed because they have to admit they were outguessed by a tech-support script after giving the support tech a hard time.
(Yeah, I like good tech support too; that’s part of why I use the local awesome option (Sonic.net) for my ISP instead of Comcast. I can call them up and talk to someone who actually knows what ARP means. But sometimes the problem does go away for months when you power-cycle the damn modem.)
Well, we don’t know that they’re actually biased in this direction until we know how their assessment of the probability that the usual thing is going on compares to the actual probability that the usual thing is going on.
Yes, there are plenty of “tech support horror stories” where the consultant has a hard time catching on to the fact that the complainant is not dealing with a usual or trivial problem, but for every one of those, there tends to be a slew of horror stories from the other end, of people getting completely wound up over something that the consultant can solve trivially, and failing to follow the simple advice needed to do so.
The consultants could be very well calibrated, and still occasionally be dramatically wrong. Beware availability bias.
Note that cases where the tech tells you that it’s usual problem X, and you deny this, asserting that your thing is a special snowflake, is NOT a case of the opposite bias. It’s just a case of correct identification.
The opposite bias would be if the usual thing was going on, but the tech thought that it was some unusual thing.
Other IT-experienced people are welcome to correct me on this, but in my experience, the latter almost never happens, and when it does, it’s mostly with newbie techies, recent hires/trainees, etc.
This makes it substantially more likely that tech people have “usual problem bias” than that they have “unusual problem bias”, and that they are well-calibrated. The usual problem bias could be small or it could be large, but available evidence is fairly clear that it exists.
The point I was making was not that tech support is likely to have an “unusual problem bias,” but that being correctly calibrated with respect to usual and unusual problems will tend to appear like a “usual problem bias” when you examine in isolation the cases where they’re wrong, because you would tend to observe cases where they need a significant amount of evidence to persuade them of the presence of an unusual problem, but not an unusual one.
If you examine cases where they’re right, you may find a large number of cases where the customer insists that the problem is not addressed by the tech support’s script, only to be proven wrong; these often appear in the horror stories posted by tech support. Thus, tech support may to some extent be rationally discounting evidence favoring unusual problems.
This brings up another related problem, namely how often supposed “experts” actually aren’t.