I don't think other fields suffer from this as much.
No one goes to the doctor and says:
- I don't feel good
- What are your symptoms?
- I don't know, I just feel bad.
What is it about computers that makes people throw their hands in air and say, I don't know, I just doesn't work.
They are smart people, and yet it's beyond them to think that, in order to fix it, the other person must at least know what's wrong in the first place.
But what looks like the exception in other areas seems to be the rule in IT.
It looks easy and clear-cut to you, because you know what is going on.
You look at an HTTPS connection issue, and you can soon discern that the crypto-suites do not match, so the connection cannot be negotiated.
You go to a mechanic (assuming you are not knowledgeable about cars), and you can at best partially describe a symptom and when it occurs and your best guess as to why it might occur. That is better than a non-technical person, its true, but a mechanic may be able to speak to you at the same level about computer problems.
As a counterpoint, look around your office at all the people who would not be able to help the mechanic diagnose a problem - they may have domain specific knowledge, but not a troubleshooting mindset.
I know very little of cars, but I used to arrive at the mechanic with a clear problem: overheating, noise while turning the wheel, flashing light on the dashboard, etc. No need to know the solution, just articulate the problem.
I fell like computers occupy almost the realm of magic in most people's mind. When it works, it's great, when it doesn't, why bother, it's beyond comprehension.
Yes they do!
And as someone who has had a lot of difficulty explaining the symptoms I've faced (I never had the concepts to describe them) it kinda drives me crazy when people assume that symptoms must always be easy to describe (the assumption usually being that if they can't be clearly articulated they somehow aren't real).
[edit: made my description a bit clearer]
"I feel like absolute crap, and I really don't know how to describe it. It's a headache, but it doesn't feel like a normal headache."
"Can you give me location? Front of the head? All over? Back of the head? Near the neck?"
"Front of the head I guess."
"Can you describe the pain?"
"It hurts intensely."
"Alright. For the average headache, can you give me a rating on a scale of 1-10 with 1 being no pain and 10 being the worst pain you've ever felt?"
"Maybe a 6?"
"Can you describe it? Does it feel like a constant pressure? Is it a sharp stabbing pain? Does it feel like a dull stimulus that creeps over you?"
Here, a patient is walking the doctor on target. And with bugs:
"The application broke."
"Can you tell me what you were doing?"
"Nothing. I just used it like normal. I wasn't trying to break anything."
"What portion of the application were you on when it stopped working? And can you show me in the application exactly what you were doing right before it stopped?"
And here, we are walking the user on target.
Of course, it would be great if we could skip the whole rigmarole if the user somehow realized that we are going to ask the exact same questions every time.
> "Can you give me location? Front of the head? All over? Back of the head? Near the neck?"
worse in some places, but I get it everywhere
> "Can you describe the pain?"
it's not pain
I don't know how to describe it.
> "Can you describe it? Does it feel like a constant pressure? Is it a sharp stabbing pain? Does it feel like a dull stimulus that creeps over you?"
No. I can't.
.
I've been dealing with this for well over 30 years.
Only in the last year have I had a bit of an explanation of why it is indescribable.
It seems likely the issue is a nerve issue, and when the nerve signals to the brain go wrong, the brain doesn't know quite how to interpret them, so you get sensations that are indescribable.
In my experience, basically everyone assumes that if there's a real problem then of course you can explain what it's like. That if you can't then that's your fault.
Sure - I didn't meant to take it that way. I just wanted to point out that doctors don't/can't always guide people towards a description.
WrongNumberException: Please use the
number three instead of four when
setting x
io.number.NumberChecker.java:123
C:\Users\Mithaldu>perl -MDoesnt::Exist
Can't locate Doesnt/Exist.pm in @INC (you may need to install the Doesnt::Exist module) (@INC contains: C:/strawberry/perl/site/lib/MSWin32-x86-multi-thread-64int C:/strawberry/perl/site/lib C:/strawberry/perl/vendor/lib C:/strawberry/perl/lib .).
BEGIN failed--compilation aborted.It reminds me of my cousin, who is a ranger in a national park, when she says something like: "Oh, the deer have been here!" whilst pointing to a patch of ground which looks totally indistinguishable from all the other patches of ground which presumably do not show traces of deer.
Your brain gets trained to see subtle changes only after several exposures to meaning. Joel Spolsky had a similar scenario where the bread making machines looked clean to a trained eye, but not to an untrained one.
A classic example: oh, I feel sick, I'm going to go to the doctor and demand antibiotics because antibiotics can fix people when they're sick. Why are the people sick? Maybe they have the flu or norovirus or rotavirus or TB, and a normal course of antibiotics is not going to help any of that. And that's a mild example, doctors have to put up with much, much worse on a regular basis. More so when you consider that people don't want to tell the truth, even to their doctor, about something potentially embarrassing (unprotected sex, drug use, bad diet, what-have-you).
SO often it's not even a statement of a problem, but just, "Why'd you break it?!" often not even stating _what_ is supposedly broken, since in their mind it's obvious.
Also, this is very, very closely related to "satisficing", which is worth understanding: https://en.wikipedia.org/wiki/Satisficing
It's pretty simple. In a company of any size, customer support is a separate job from development. Asking a programmer to field support calls is like asking an architect to trim grass.
Contrast this with tech, where users are treated like idiots and the first question asked in a tech support interaction is the cliched "have you turned it off and on again" joke. Maybe we need to approach this more like the doctors and librarians do.
Once it reaches the point where the problem has been clearly isolated and the soliton path identified, I usually don't count it as a problem anymore.
Think of all the progress in science and medicine there's been over the centuries, where we've developed understandings and ways of describing things that we didn't have in the past. The actual things being described always existed, we just didn't understand them or know how to describe them. It's got nothing to do with metaphysics at all. It's about our human limitations.
Speaking from my own experience, I had medical symptoms for over 30 years that I didn't know how to explain. There doesn't seem to be any existing concepts for them.
I have only very recently come to realise that they are probably due to some sort of nerve-related issues -- where this is the reason why they're hard to explain. Something is causing problems with the signals to the brain, so the brain doesn't quite know how to interpret it, which is why you get something indescribable. (or at least that's what seems likely to be going on in my case).
This is the email I sent to my hosting company a couple of years ago when WHM (a component of cPanel) started doing something silly that broke my SSHD:
sshd and ip whitelisting - there's a bug it seems
If I go to whitelist my current ip in whm, it asks me to restart sshd to
make the changes stick. If I do that, sshd fails to restart with an
error like this:
Directive 'UseDNS' is not allowed within a Match block [FAILED]
I presume what's actually causing this is some script in whm that goes
and adds something like this bit in sshd_config:
Match User [my user name]
PasswordAuthentication yes
UseDNS no
The "UseDNS no" should be _before_ the "Match user ... "etc (that's the
match block from the error message).
I've no idea what part of whm is doing this but it's doing it wrong- get
someone who knows perl to fix it, it should be dead easy.
My doctor has advised me to stay away from perl for life
I never heard back from them. I think that's an informative message, isn't it? I (a) relayed the error message (b) pointed at the cause of the error message (c) explained how to fix it
But they didn't even write back to say that yeah, they knew and were going to fix it. Isn't that a shame?
"It should take somebody 20 minutes to fix this if they know python"
What bothers me is if someone starts acting like they're entitled to my help and time. What bothers me more is when they act like they're entitled to a complete solution, rather than hints, explanations, and recommendations. No, I'm not going to code your homework assignment for you, sorry.
The response? 'Could you please send a video showing when the problem happens'.
bangs head on desk
This battle is indeed being fought since forever [0], of which this blog post is basically the nth dupe of.
I did fib a bit though. There is one error we get emailed to us regularly. It's a 403:
{"code": "Forbidden",
"message": "You do not have access to this
API feature because you need to be a member
of role [ROLE]. To get access, follow this
link to our role request page here:
https://linkToRoleRequestPageWithDeadSimpleHTMLForm?role=ROLE"}
EDIT: I'm also talking about the JSON output of an internal API whose target audience is developers and people writing scripts. This means that we are all the problem. If the target customer were average Joe user I'd completely understand.
How about. "Forbidden. Please request access by following this link: http://internal/?requestguid=GUID&custn=CUSTNAME
Your request will be handled within 24 hours."
That link?
If they click the link - which they will - you have all the information they should email you (but don't.) Because you told us all you need is the GUID.
Remember: Error messages are literally an API between you and the human. If the human isn't doing what you want, you need to debug your API code until the human is doing what you want. The human is like a device! It might be flaky, but you're stuck with it. So debug your API code (the error message) until you work around the flaky humans.
I'm going to change all error messages to:
"Please click this link and type the following GUID into the web page."
That way, based on history, I'll at least get an email with the error copied in. They'll never click the link, but if they do one or the other, I'll have the info I need.
Now if I could just stop people from submitting bug reports for 404 errors...
"If you ignore that link and instead email this to us, we'll try to get back to you within 5 business days."
I get such bug reports for my open source project. People get offended when I point out that the message says what they need to do.
The only reliable way around it we've found with our clients is to be dickish with SLAs: insufficient information means the SLA clock stops dead. No error code/message details, no SLA, and I can & do take my merry time (if I ever get around to looking at that ticket instead of the many that do have sufficient information).
Though it helps that our large clients always knock down support costs by refusing to pay for first-line support because "our internal helpdesk can do that" so they should be performing at least minimal triage. It might not wash in other environments.
The really irritating part is when they seem to do their level best to avoid giving any specific details:
Them: some users are having a problem with a form
Us: which users? Could you name at least some, and if any don't have the problem name at least one of them. And which form? And do they get a specific error?
Them: Actually it is quite a few users.
Us: which users? Could you name at least some, and if any don't have the problem name at least one of them. And which form? And do they get a specific error? Is the problem loading information or saving it? IF the latter does any of the data save despite the error?
Them: More users are now reporting the error.
Us: which users? Could you name at least some, and if any don't have the problem name at least one of them. And which form? And do they get a specific error? Is the problem loading information or saving it? IF the latter does any of the data save despite the error?
Lather, rince, repeat, until I state something like "we've tried with several user types and several forms in our test services, and can't reproduce the problem, unless you can produce the details requested we'll have to close the ticket as "can not reproduce", at which point they get shirty about us not being helpful but do provide the information requested.
Yes, I can often work out exactly what is going on from various exception logs, and sometimes to just to get the buggers off my back so I can get on with something more useful and interesting, but I resent having to dig for details that it would take almost no effort for them to provide either up front or after my initial request for clarification. IT isn't just "lay users" either, it is often people who really really should know better. IF you find yourself on the other side of this equation: give all the detail you can FFS, help us help you (countpoint: only give us facts, don't guess or otherwise make shit up).
there seem to be some serious issue with your QA training. soon I will be looking for job in QA, I can only hope there are more companies like yours giving me better chances :)
1. Write decent documentation, i.e. actual user guides instead of reference manuals. Most software is under-documented by an order of magnitude and the documentation is simply terrible.
2. Write log messages that are meaningful to the intended users (end-users, sys admins, etc.) instead of "Error 3023: 0xFFFF flux capacitor initialization exception".
3. Make the software interactively help the user overcome the problem. Put some smarts into it. Showing an error popup and then crashing is lazy. Or worse, crash silently and then write a log message that the user can neither find nor understand.
Yes, people are dumb but we do a lot dumb things too. We should look at ourselves first.
Then, you had a large group of people who had some degree of imposter syndrome and felt inferior to the first group, partly because the first group seemed so confident. They would avoid situations where they might get called out or blamed. Often their insecurity would lead to more mistakes or poor explanations once they did occur.
I wonder if this same phenomenon might be occurring in your situation?
I imagine in corporate environments people want to seem favorable to their bosses for bonuses and what have you. Also, and especially at large tech companies, you would have procedure, process, and tooling, that was relied on heavily and whenever something out of the ordinary cropped up that the tooling did not hand hold them through, would put them in a loop.
That's interesting, at my job we almost get these: we tend to dump tracebacks to the user, and it's common for them to screenshot the traceback (despite the "copy this error" button).
Maybe you should have some sort of inline reporting interface à la Apple where the user can tell you what they were doing and provide contact info?
I also get a lot of near-misses, where they almost get it right: for example, copying the bit that says "there was an error, please include the information below when you report it" without actually copying the stack trace underneath the message, or copying the first line of the error which says "cannot read property id of undefined" without the stack trace that would tell me what it was trying to do at the time. Also, users who paraphrase the error message instead of copying it (Them: "When I try to view a Thingie, I get an error that it couldn't be read." Me: "Can you copy the exact error message please? There are several different reasons that a Thingie might not be readable, the error should tell me what I need to fix.")
It doesn't help matters that some of the software I inherited uses this antipattern:
try {
// Long and complex operation
} catch (Exception e) {
Alert("There was an error. Please contact IT.");
quit();
}
Yes I forgot to write that part in: while we rarely get the "screenshot pasted in word" (which IIRC stores the full image by default so you may be able to recover it, yay) the screenshotted traceback is usually cut off at the bottom, so we get the least useful part (wow I get the stack information of the WSGI handler, well that's going to be helpful) but commonly don't get the actually interesting part.
> It doesn't help matters that some of the software I inherited uses this antipattern: […]
Fuck everything about that with a rusty bonesaw.
Got this from the "IT person" at a small satellite campus of the college I work for. That is how I knew they were not actually an IT person.
My favorite, which was particular to a certain nationality, was this one (which we got quite often):
"The Internet is down. Please do the needful."
Sounds like a word to word translation from french "Merci de faire le nécessaire".
You're complaining about such a message??? It's pure poetry!
I'm constantly baffled by bug reports I receive. From other people who work at my company. A tech company. A large one. You've heard of it.
We log every operation in our API. I cache errors, and the API returns a JSON formatted error with a GUID that correlates to the operation that failed, so if I have a GUID I can look at exactly what happened every step of the way, and what went wrong, in the logs.
Most of the time, all I need to fix a bug or tell you why you're having a problem is the GUID from the error message. You don't even need to ASK a question. I log stack traces of any exceptions that occur so our logs are almost as good as running the software through a debugger.
The bug reports I'd expect and want?
I have NEVER gotten that bug report. The bug reports I get? Or my favorite:"Hey, we've been discussing this issue we've had with <upstream system> that depends on your system. We assumed your system has been down for the last couple of days and have been blaming your team in email threads you're not on because <upstream system> isn't working. Nobody told you or your team. When is your system going to be fixed? No we don't have any examples or any record of error messages from your system."
(Resolution: problem is bug in <upstream system>)