Why Won't You Answer My Question?
rion.io
rion.io
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?
"Hey, I got this error message that I copy/pasted below...can you tell me what's going on?"
<two line error message>
"Hey I think your system is down."
"Is something wrong with your system?"
"I tried to do something and got an error. Is something wrong? No, I don't know what the error was."
"We're getting this weird error when we try X. I dunno, it was just weird. It works now though."
"I think the data you're returning is wrong."
"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>)
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.
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).
WrongNumberException: Please use the
number three instead of four when
setting x
io.number.NumberChecker.java:123
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.
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.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
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.
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.
"If you ignore that link and instead email this to us, we'll try to get back to you within 5 business days."
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...
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).
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.
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 :)
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."
You're complaining about such a message??? It's pure poetry!
Sounds like a word to word translation from french "Merci de faire le nécessaire".
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.
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.
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();
}
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.
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.
Here's a resource to deal with it:
https://www.mikeash.com/getting_answers.html
Here's another, somewhat harsher version that preceded that:
http://www.catb.org/esr/faqs/smart-questions.html
These were discussed on the C2 wiki a long time ago:
http://wiki.c2.com/?HowToAskQuestionsTheSmartWay
But the issues remain - people are sometimes lazy, sometimes asses, sometimes jerks, and often suffer from learned helplessness.[0] In each case, answering their question is not always the right thing to do.
Somehow, I've lost most of that "helping gene" over the years. I'll still happily explain things to people, but I don't look for occasions to explain stuff on purpose anymore.
Getting no questions at all.
This means that nobody is using your project, and that makes me feel defeated far more than having person ask me why he uploaded my project's python files to public_html on his $2 shared hosting, and no app is showing up in his browser.
Perhaps that's not working? Perhaps its time to consider other approaches especially since complaints with such detailed advice for resolution ARE NOT READ by the people that actually need to read them? How is sharing this on HN REALLY going to help people ask better questions?
Many tech people fail to understand that having knowledge and giving knowledge are two distinct things. Just because you know something in great detail and can practice it with fantastic skill, doesn't mean you're able to answer basic questions about it or teach anyone to do the same. The problem is not just "asking the right question" but also the skill of "giving the right answer".
To a large extent this territory is covered well by teachers of all kinds. Pedagogy itself takes practice. I wonder if anyone has written a blog post with a 21 point checklist on how to ANSWER questions?
I try to shepherd to StackOverflow asking for at least a code sample and some attempt at implementation where I am happy to answer. I've also done interventions with the offending person. But at least, no avail, it continues. They go to the local communities of other countries on Facebook and ask the same question, often in all caps.
I am trying to write a full guide and example on "how to do X", but these cases are very testing.
1. what did you do?
2. what did you get?
3. what did you expect?
If people get resentful when you ask for data, the solution is to have a discussion about their poor attitude.
Most large companies I've been at are terrible at this. They want "professionalism", which tends to mean "superficially polite, even if the questions are utterly retarded". They don't like "unprofessional" behavior, which tends to mean "you got frustrated that someone else wasn't doing his job".
The effect is that management pushed people to be incompetent, in the guise of "getting along". The competent technical people tend to leave such organizations.
I know what you mean and I agree but unfortunately most people don't.
I'm somewhat privileged to have had a 20 year career in mostly competent workplaces, and I understand that in some places where engineers are held in low regard that you might get a lot of "stop asking questions and fix the damn problem already", but it never hurts to cultivate a pleasant disposition in the workplace.
Practically speaking though, my advice for people stuck on something like this is (in addition to doing some actual research and wording your question correctly) to not ask on question and answer sites at all. Stack Overflow is nice and all (especially when looking up answers to already answered questions), but I tend to get a lot more useful responses from forums and subreddits. Perhaps because people there tend not to get so high strung over idiocy.
Or what if the asker has a misunderstanding of computer architecture? "Help, my multithreaded program is crashing!"
However, it's also the kind of thing tech support has to deal with every day to begin with. I mean, your web host likely gets tons of ridiculous questions through their support ticket system. They just have to go back and forth a ton of times until either both sides can reach an understanding or the person asking just gives up.
Honestly, I don't have an answer here. Not sure there even is a good one, given how it's the same problem every company struggles with when customer support is involved.
Bountify sort of fits this. https://bountify.co/
To come up with a good question requires some level-headed thinking. Give too little information and it's hard to get help. Give too much, and you're either leading support down the wrong path or overwhelming them with useless data (which, somehow, annoys me when people do it to me, which doesn't help).
But because our mind is in agitation/panic mode, we just randomly try stuff, including thoughtless cries for help.
What I find interesting is that I'm just as susceptible to this when it comes to issues with my own work. I've been doing this for quite a while now, and yet I still regularly either thoughtlessly play whack-a-mole with a bug, or alternatively go down some obscure rabbit-hole of searching for answers. Very often in both cases the problem would've been easily solved with a clear head and a methodic approach (no matter which approach, really).
Hell, that's the whole reason 'rubber duck debugging' is a thing and so effective!
I'd say all this applies equally to things like conflicts or relationship issues. So many problems I've had over the years with people just melted away once both parties bothered to stop and think about how they communicate, or even just deciding what the actual problem is. But of course that's the last thing you do in a state of agitation.
A good page about the proper way to ask questions/reporting problems on the internet is (was) here (among many other good FGA's), to avoid the common "I'm ill, doctor. Help!" effect:
https://web-beta.archive.org/web/20160520121511/http://homep...
https://web-beta.archive.org/web/20160604095422/http://homep...
Instead of searching the Internet I started really get to know the API and libraries of the languages I used and I got good books on the topics of software I develop. I slowly moved away from searching the Internet for a solution to using the books and delved into the language API. I now feel I've a deeper knowledge of the languages I work with and the techniques used to solve problems in my field.
Now when time is against me and I need a quick answer to a problem I search the Internet for an existing answer.
I always find it sad when people are impressed that I "can program." Not only because people tend to think of it as binary when it's not, but because they think programming, like math, is the exclusive domain of people with certain inherent qualities.
Part of the entitlement problem does not seem to be limited to development. There’s a lot of overlap with the way people are being treated in retail, for example. What the hell is it about “I am trying to help you” that just makes some people turn into tyrants and treat helpers like part of the problem?
If the questions come by email, delete the email. Not a difficult operation.
If you encounter stupid questions due to your participation in a website, stop visiting that website, or stop answering questions on the website. Not a difficult operation.
The people who write long screeds about answering/asking questions are all masochists.
They don't have brains, and want to eat yours.
"HELP ME" "HELLLLLLLPPPPPP MEEEEEEE"
they screech in the title of their emails and forum posts
Don't be fooled. There is no helping them.
Pardon my humor. I do my share of helping, and seeking of help.