Haha, yeah go ahead and try to fight this battle. You'll lose.
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>
I have NEVER gotten that bug report. The bug reports I get?
"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."
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."
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.
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.
> 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).
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.
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.
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.
> 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.
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.
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?
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'.
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.
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.
"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 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. :)
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.
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.
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.
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: […]
>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.
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):
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.
I admire anyone who has the patience to answer questions on places like Stack Overflow or mailing lists. I don't have that particular helping gene. I'll help you move, though.
I had when I was a teenager; I'd spend endless hours explaining C++ to people on Internet forums. It was a kind of pastime for me.
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.
For me it has a few factors: I learn, memorize, and internalize through argument and learning to explain things to others. Eventually my skill ceiling rises in a topic where this no longer applies much. But, if I can spend 5 seconds to save someone 5 hours, I'm likely to help unless I thoroughly dislike the person - it's just too high of a positive impact. With my peers, I'll accept much worse ratios (e.g. spend 1 hour to save you 2) under the vague unstated assumption that you'd do the same for me, or it'll help accomplish our common goal faster. And in the special case of helping people with research and problem solving skills, it'll sometimes make people less annoying :)
Doing open source in my free time, I've found solace in realizing what is worse than getting barrage of unresearched, silly, or perhaps bad questions:
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.
... and if you do heed the advice of the OP, and post a well-considered question on stackoverflow, researched to the best of your ability, you will often get back a withering dismissal from some asshole who has taken it upon himself to police against "bad questions".
What we have here is literally a 21-point checklist that someone needs to go through before deigning to ask a question so as not to piss off the IT guy. We've all seen it before, hundreds of times, stackoverflow has made asking a question into a sacrament, yes, with the same level of sanctimony.
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?
A variant of rubber-duck debugging: Ask the question and hit Send. Invariably, no matter how long I've thought about it, the obvious answer will occur to me minutes (or seconds) after I've embarrassed myself my asking. (is there a term for this?)
Similar to remembering you forgot your keys the moment you step outside and shut the door. My theory is that stop deliberately struggling to think and your brain is suddenly free to start processing things subconsciously, which can generate solutions to complex problems.
In one rare case of my project, there is a person that bombards every single one of the project's social channels daily (Facebook, multiple Slack channels, DMs) with the same question: "how do i do this? <link to some website>". Asking questions is fine, but there's a point where they can be taking hundreds of people's time (even for a second).
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.
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.
Mm, I've never had a problem asking those 3 questions of any non-technical person that comes to me for help. Whether it's perceived as polite or not is entirely contained in the tone. You can say that exact terse statements very politely or very rudely or anywhere in between.
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.
Makes me wonder if there's an opportunity here. Some service where you can actually pay money up front to guarantee an answer to your question, regardless of how it's worded and expect it done within a short time frame. Kind of like the Stack Exchange sites, except for people with more money than patience.
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.
Except that the money people will be willing to offer will almost certainly not cover the amount required by any competent professional to pay for their time, i.e USD 100+ per hour. And if someone is willing to pay, say, five hundred dollars for a complex solution that requires effectively half a days consulting, they'd probably be better to just hire an actual consultant.
That would be quite an interesting site. I put up some cash in my account and then ask a question. It would be an interesting dynamic if other people needing the same answer added money to the bounty for the answer, or even the original person upping the offer. Easy revenue stream as a tax on the bounty. That would be a fun one.
That's a good point, and there will definitely be issues with question askers not knowing how a system works or how the person answering is explaining the solution to their problem.
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.
There is one platform where I am in but as many freelancer marketplaces with free entry it's a sh*tshow and a race to the bottom, so I won't even bother recommending it.
> Makes me wonder if there's an opportunity here. Some service where you can actually pay money up front to guarantee an answer to your question, regardless of how it's worded and expect it done within a short time frame. Kind of like the Stack Exchange sites, except for people with more money than patience.
From personal experience, telling tech support too little about an error will result in no solution. Being able to tell them too much, oddly, often results in the same.
I think that's kind of the core of the issue. When faced with a problem, in general, it can produce a kind of knee-jerk/panicked reaction.
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.
But I guess that somewhere a line must be drawn, there is a difference between a "common user" and a "software engineer", and as well some differences between people that try to help strangers on "third party" issues for free and a developer supporting his/her (paying) customers or debugging his/her company internal issues.
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:
I used to do a lot of searching the Internet for a solution to a problem I ran into while coding and then I ended up having a bunch of web-links to fixes I didn't write. I got annoyed with myself about this.
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 haven't taken much CS, but I took a class on computationally intensive statistics. It changed my life, because every week I was assigned to do things that we hardly covered in class. I felt so lost for while, until I got the hang of the stuff described in this post. It's really empowering. The only constraint becomes time, not intelligence.
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.
To add to the Google point, it makes a big difference to add some double-quotes around the multi-word phrases that belong together (especially when most of your issue is made up of common English words).
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?
I sometimes use a variant of rubber duck debugging. Two projects I have been responsible for started by me taking over from a contractor who was on-call to resolve issues. I would start an email to him describing the problems and asking good questions. More often as my understanding of the systems progressed the emails would not get sent since the act of explaining it to someone I knew could fix the problem led me to understand the error.
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.
I don't know if that's true, but it certainly feels that way - some people seem to be unable to ever learn how to ask for help. I don't know the reasons, be it laziness, low IQ, other character traits, learned and ingrained attitudes, whatever - but they are extremely resistant to any kind of education on how to solve problems (and asking for help is one of the skills included in problem-solving). For such people the term "help-me zombie" is quite fitting, I feel.
It's not about IQ, it's about knowing how to learn. Being able to teach yourself something is a skill, which most people don't realise. Knowing how to find information isn't something you're born with.
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>)