Hacker News Reader

Oh god yes. I don't understand why it's so hard for people to report a bug.

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.

It's usually in the form of: "I have a sore throats and running a fever, it began x days ago", etc

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.

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.

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

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.

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.

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.

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

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

Hah. You think most techies want to get informative error reporting from their users?

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

That was after I spent an hour or so chatting with their tech support to try and unscrew my SSHD after it suddendly stopped authenticating me (probably because they updated to a borked version of whm). So yeah, they knew what I was talking about alright (and, yes, I sent that to the right people, check).

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?

"Should be easy" is a bozo bit phrase. Whether it should be that way or not, you're going into the slow bucket at that point.

Indeed I had a discussion on reddit recently, trying to help somebody. Their exact words;

   "It should take somebody 20 minutes to fix this if they know python"

At that point I was done with the conversation, though I was tempted to ask what their bug-fixing-budget was..

When someone asks me to provide them a fixed version of their code, that's when their problem completely stops being my problem (unless there's something unusually interesting about the code, maybe).

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.

Oh oh time to commiserate. I reported a software problem with a QNAP NAS to their tech support. I dug out the logs (that weren't included with their 'official' diagnostics tool, these were logs somewhere deep down in an undocumented directory for which you had to set an environment variable for them to actually be generated). Those logs included stack traces from their Python code, complete with the name and description which essentially said 'socked timed out'. I described why the issue was happening (including links to the documentation of the 3rd party service they are integrating with, as well as quotes from tech support of that 3rd party company saying what the issue is). I then went on to describe how to reproduce, and under which circumstances it can be reproduced; complete with a high-level conceptual description of how things fit together.

The response? 'Could you please send a video showing when the problem happens'.

bangs head on desk

> Haha, yeah go ahead and try to fight this battle. You'll lose

This battle is indeed being fought since forever [0], of which this blog post is basically the nth dupe of.

[0]: http://catb.org/~esr/faqs/smart-questions.html

Yeah I came here just to post this link since this was one of the first guides I literally printed out and had on my desk per request of an old friend.

Change the first line of your error message to, "Important: Please mention the following error number when contacting support." you told us that is what you need - but did you tell the user?

Doesn't matter what the error message is. It's very unlikely they're reading the error message at all. And yes, I've tried what you mentioned.

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

THAT error reliably gets copy/pasted in an email to us with the questions "Why am I getting this error?" or "How do I get access to this?"

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.

So you need to lie in your error messages and come up with a message that will get emailed to you.

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.

You forgot the important extra part:

"If you ignore that link and instead email this to us, we'll try to get back to you within 5 business days."

I don't think there's any reason to be passive aggressive. If you give users two options they'll choose the one that's worse for you and worse for them. :)

I like the way you think.

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

:) good luck!

My $0.02 is that people who submit such bug reports need to be fired. They're adding negative value to the company.

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.

Doesn't work. Too many people don't read the instructions, or do but don't follow them, not matter how much big, red, bold, flashing text tricks you use.

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

I get bug reports like that from our QA team! The people whose specialized job it is to report bugs write one line bug reports like "<Feature> doesn't work". No stack traces, no environment information, no steps to reproduce.

are they hiring? :-) can't imagine those QA people are not fired, I always at least try to provide steps to reproduce and expected result if possible, and of course it should be accompanied by some system log

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

Well, you can try to make people smarter (good luck with that!) or you could focus on something you can actually control such as delivering better software. Three things we as software developers normally do poorly that could help a lot:

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.

Ah, I love "weird errors." I'm not sure there's any other adjective that's ever used, they're always weird.

Your workplace is much more polite than my ones have been. Dropping the odd F-bomb equated to a low level error, with appropriate scaling from there.

I remember back in high school seeing two dominant attitudes when it came to issues like this. You would have one group of very intelligent people who were very confident in their decisions and on the odd occasion where they made a mistake would often blame something or someone else. Worse they would frequently scoff at the mere suggestion they were wrong.

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.

> I have NEVER gotten that bug report.

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 get the same thing--or worse, screen shot pasted into a Word document that's attached to the email, so their two monitors are squished into 8.5 inches and any text is scaled down to illegibility.

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();
    }

The first time I got a report for this software was rather confusing. "It says there was an error." "Can you tell me what the error message says?" "Yes, it says 'there was an error.'" "I know, but what was the error message?" "'There was an error!'"

>I get the same thing--or worse, screen shot pasted into a Word document that's attached to the email, so their two monitors are squished into 8.5 inches and any text is scaled down to illegibility.

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.

> I get the same thing--or worse, screen shot pasted into a Word document that's attached to the email, so their two monitors are squished into 8.5 inches and any text is scaled down to illegibility.

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.

Nothing new under the Sun. When I was getting my C.S. degree in the mid-90's I worked at the same time for the C.S. department as an SA. (Actually, they called us sysops at the time.) Anyway, I saw all the help requests that came in from students and faculty. These are C.S. students and faculty mind you. It seemed the further along someone was in their C.S. education the worse the help requests would get.

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

> "The Internet is down. Please do the needful."

You're complaining about such a message??? It's pure poetry!

> certain nationality

Sounds like a word to word translation from french "Merci de faire le nécessaire".

could be also any slavic language, they use it in same way

"do the needful" is en-IN-ism:

http://travel.cnn.com/mumbai/life/10-indianisms-652344/