Comment by moring
18 hours ago
He doesn't give the chairman due credit, IMHO. The chairman collected information to help solve the problem AND it actually was the information needed. Without it, the author might look for "randomly unreachable servers" for a long time.
It's almost raw data -- exactly what you would wish for. By lecturing people that "email does not work that way", next time you either get no data at all because people don't even try, or no data because people hide it thinking email doesn't work that way, or a misguided conclusion when a layman tries to make a better guess at the cause of the problem.
Absolutely. It's one of my all time favourites stories and this is pretty much the reason why. I wish my users gave me such specific steps to reproduce!
What's my recent annoyance is that users will describe their problem in great detail if they are talking to LLM, yet same people make just as shit support tickets as before
(1) disguise as an LLM to have them give better problem descriptions to you (2) provide an LLM for your users that lets you read their chat to understand their problem
and:
(3) try to understand why they are communicating differently to an LLM. Immediate replies? Different feelings knowing they don't talk to a human? Genuinely better help? Not getting treated as stupid?
All or none of these may be true, but if it's consistent behaviour then there is a reason for it.
I guess people won't feel judged or shamed for not knowing something from an LLM.
It helps to have a statistician and a geostatistician as your clients!
I do wonder if they already had a feeling it was not supposed to work that way hence the info gathering. This is one of my favorite all time IT stories because the client was right, and the engineer was left almost going crazy.
When I was a Junior I asked an honest question to the senior I was working with at the time, great dude, I basically asked him because everyone joked about the "works on my machine" crowd, so I said, so what the heck do I do if it only works on my machine? He said you have to figure out what's different. It sounds obvious or simple, but if you go with that mindset, when someone's stuck in the "it works on my machine idk why" sure enough I ask "what is DIFFERENT from your machine and this one?" and it almost always leads to the right answers. It triggers something in our brains. I usually follow up whats different with "what was the last change?" in the case of a production issue.
Fantastic comment. Indeed.