I think it’s a particular skill to phrase requests for help in such a way to list as many relevant steps that you tried as briefly as possible and judiciously decide not to mention all the steps you’ve tried tempting though it may be. I had for a long time in the context of tech support questions written very long help requests because I was so afraid of getting a glib response to try some extremely obvious thing that takes 5 seconds and would definitely fix some well known easily solvable issue but not the harder more obscure issue I was experiencing that happened to have characteristics of that simpler issue.
I learned though that the longer your request is the less chance you have of receivingany help and if it’s a captive audience who are required to help you, the more chance you’ll have of them getting rid of you by deliberately misinterpreting the issue by focussing on any random part of the very long description (could be the opening sentence, could be something several paragraphs in) and pretending the request was all about that. They’d hone in on steps I described taking to try and fix the issue I wrote the help request about in the first place, re-contextualise those steps as a different, unrelated help request and then give an unhelpful response on how to solve that issue that I was never experiencing to begin with. More innocently, long lists of what’s been tried also just make it harder to understand the problem when someone is trying to assist by virtue of the sheer volume of text produced and how boring and tedious it becomes for them to read. There’s also another issue in being too fixated on listing what’s been tried which is that, although the whole idea is to filter out responses that involve solutions that have already been attempted, often it transpires that you didn’t actually attempt the solution in the right way and something dismissed as ineffectual actually would have worked after all. Sometimes it’s actually better to let people suggest something you already tried and anticipated they might suggest, just so you can double check that you actually really did try that approach properly and didn’t have a faulty understanding of how to apply it.
That said though, obviously I try to make sure to include the things I’m very confident I don’t need to try again to show that indeed I’ve worked on the problem and have tried the more obvious solutions already.
Someone posted for software help on some forum about something and… they described everything. I shit you not, their description was a determinate system in it of itself.
I think it’s a particular skill to phrase requests for help in such a way to list as many relevant steps that you tried as briefly as possible and judiciously decide not to mention all the steps you’ve tried tempting though it may be. I had for a long time in the context of tech support questions written very long help requests because I was so afraid of getting a glib response to try some extremely obvious thing that takes 5 seconds and would definitely fix some well known easily solvable issue but not the harder more obscure issue I was experiencing that happened to have characteristics of that simpler issue.
I learned though that the longer your request is the less chance you have of receivingany help and if it’s a captive audience who are required to help you, the more chance you’ll have of them getting rid of you by deliberately misinterpreting the issue by focussing on any random part of the very long description (could be the opening sentence, could be something several paragraphs in) and pretending the request was all about that. They’d hone in on steps I described taking to try and fix the issue I wrote the help request about in the first place, re-contextualise those steps as a different, unrelated help request and then give an unhelpful response on how to solve that issue that I was never experiencing to begin with. More innocently, long lists of what’s been tried also just make it harder to understand the problem when someone is trying to assist by virtue of the sheer volume of text produced and how boring and tedious it becomes for them to read. There’s also another issue in being too fixated on listing what’s been tried which is that, although the whole idea is to filter out responses that involve solutions that have already been attempted, often it transpires that you didn’t actually attempt the solution in the right way and something dismissed as ineffectual actually would have worked after all. Sometimes it’s actually better to let people suggest something you already tried and anticipated they might suggest, just so you can double check that you actually really did try that approach properly and didn’t have a faulty understanding of how to apply it.
That said though, obviously I try to make sure to include the things I’m very confident I don’t need to try again to show that indeed I’ve worked on the problem and have tried the more obvious solutions already.
Funny, I saw this to an extreme, a ways back.
Someone posted for software help on some forum about something and… they described everything. I shit you not, their description was a determinate system in it of itself.
CPU, GPU, SSD, ram, thermal fans, size measurements, age, resolution, price point, model, kernel version, installed package count, filesystem setup, update log, journalctl, dmesg, Xorg log, genome sequence. And the kicker?
First comment:
No other comments.
Haha almost sounds like my style before refining this skill, although maybe not that extreme.