My father is a doctor. I assure you, you are overestimating the ability of (some) people to report specific symptoms.

It may very well be that I'm biased since it's my field.

But what looks like the exception in other areas seems to be the rule in IT.

I'm sure there's a name for this phenomenon, but every field is like this.

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 think you're onto something regarding the 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.

I don't know, I'm sure mechanics deal with a lot of "my car has a strange sound". Or people not admiting that there's anything wrong with it. It's probably more that there aren't many things except computers and cars which are both ubiquitous and breakable.

Not enough people grew up listening to Car Talk on NPR.

> No one goes to the doctor and says: [...] - I don't know, I just feel bad.

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]

Had a family member who got sick traveling over in Japan. He can speak Japanese OK - enough to get around and have conversations, but he got sick. In a smallish village. At night. Found one chemist open late. Trying to describe your symptoms in your native tongue is hard enough - trying to do it in a language you're not fluent in was multiple steps harder. That was one of those crazy stupid "oh yeah, that could happen" situations that never crossed my mind when traveling abroad.

But at least with a doctor visit, the doctor can start lobbing mortar shells, and you have the ability to help walk the doc on target. I feel like this analogy is very apt, because to better troubleshoot, developers/IT can try to help testers/clients/customers walk the issue on target.

"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.

It's not always this straightforwards. To talk of my own situation:

> "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.

I didn't mean this to minimize other peoples' experiences. That example was a dramatized version from my own life when I started having daily migraines. The symptoms I initially gave to the neurologist were all correct, but they were broad. In addition, there were a few related symptoms that I had not realized were connected until I was probed about them.

> I didn't mean this to minimize other peoples' experiences.

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.

One thing that is also frustrating is apparently intelligent people (even software engineers, while writing code) who see a stack trace and their mind goes blank. They then send you an error report saying 'I set X to 4 in my code and got this exception, here is the stack trace - what's wrong, and how do I fix it?' followed by something like:

    WrongNumberException: Please use the
    number three instead of four when
    setting x
      io.number.NumberChecker.java:123

Of course many error messages are completely inscrutable, but it seems nobody reads any of them, parsing it as 'computer says complicated thing' or similar...?

If only all error messages would be that helpful, dev work would be significantly simpler. Instead I rely on the source, or decompilers to figure out why shit doesn't work.

The most ignored real error like this that i see continuously is:

    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.

Not to exclude the X factor, but presentation matters. I think vomiting exceptions, stack traces, or error codes in text makes people not care. Not just a layman, but an expert, too.

This is very true. A verbose log is incredibly helpful to someone who can read them, but if you are unfamiliar with the format, or find bits that you cannot interpret, then it all starts to look like noise.

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.

It gives me hope for a solution, since then I've got some text strings to throw at google. Otherwise, I'm back to starting with "$program_name crash", because I don't want to use search terms that would exclude someone's wording describing the same problem.

Bahahaha, no, that's exactly the problem doctors have. "House", for all its theatrics, does get a few things right. People are bad when it comes to their health, which is compounded by medical/physiological ignorance. You'd be surprised what people know, what they're willing to tolerate and rationalize, what they're willing to discount, what they're willing to convince themselves of. A common pattern in tech and medicine (and all things really) is for someone to map a problem onto some crude misunderstanding and then state the problem not in the form of a problem but in the form of an unimplemented solution they've thought up.

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).

And to bring it back to IT, we get this same thing all the time too. So often I get emails where people just launch into these convoluted accusations of how (made up example) I made our site stop working in desktop browsers because all we care about is phones now because that's where the money is (or some such insanity). Turns out it's actually some malware screwing up their copy of IE9 or whatever.

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.

I get these alot aswell, especially from more senior testers that never woorked as developers. They make up some crude model of a solution for what they think the problem is that they concluded from god knows what.

See also, the XY problem. https://meta.stackexchange.com/questions/66377/what-is-the-x...

Ah, it has a name, nice.

Also, this is very, very closely related to "satisficing", which is worth understanding: https://en.wikipedia.org/wiki/Satisficing

Actually, doctors are trained to ask questions to elicit specific descriptions of symptoms precisely because people all the time do pretty much what you say they never do.

Those of us who are good at addressing user-reported issues learn to do the same. No one in our industry seems much to teach this skill. I wonder why.

> No one in our industry seems much to teach this skill. I wonder why.

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.

Yet, if they did so perhaps the architect would stop putting grass in places where it's too f'ing difficult to actually maintain properly. Sometimes putting the 'expert' in the shoes of the 'maintainer' works wonders toward creating designs than can actually be maintained.

Similarly, reference librarians receive reference interview training to get a better idea of what information patrons are seeking. There were several MDs in my LIS cohort who remarked on the similarity between reference interviewing and medical interviewing.

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.

In fairness, the biggest problems in life are those where something is wrong but you can't clearly define what it is.

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.

We're reaching metaphysics here, but yeah, it's a good point.

Hardly metaphysics. As if anything that we don't have good language for describing must be metaphysics.

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).

One reason is they assume you already know about the bug. Surely thousands of other users have reported it already. So you probably already have a workaround ready or know when it'll be fixed. Their vague description is really just meant to remind you which bug they're talking about, not help you discover it.

Writing good bug reports is a skill that is, in my experience, only taught to software testers, and even then only informally. My first job out of college was Software Test Engineer (STE) at a large software company that was plenty mature enough to have formal training around these things, and yet during my first week on the job my mentor instructed me to query the bug reporting system for bugs written by particular STEs on our team because they were known to write well-structured, quality reports. This was not a terrible way to learn how to write a good bug report -- I learned a lot from this exercise -- but it's not exactly a good way to evenly distribute such knowledge across entire teams or companies.