I might as well go first: Basic troubleshooting and reasoning.
I mean, we’re not talking debugging assembly language here. But at least you should be able to reply correctly to the question “is it dead or faulty?” when it comes to a computer. And when a your car has a weird noise, at least try to locate it for an obvious cause such as something rolling around under your seat.
EDIT: And one important aspect of troubleshooting many people don’t get is how to narrow down the problem. Let’s say your wifi isn’t working - have you checked on any other device whether it’s working there? Someone else mentioned binary search which has a lot of overlap with this.
I used to work with internet on trains, and the system was relatively simple by today’s standards. Not so much back then, but:
One carriage had UMTS/LTE and CDMA modems and a router that load balanced between the uplinks. Usually in the restaurant carriage, because there would only be one per train. It also had a short range wireless link in each end for other carriages to connect.
Each carriage that could potentially be in the same train had wireless clients in each end for connecting “upstream” towards the router.
All carriages had a wifi radio
On other words, many potential points of failure. And sometimes we’d get tickets such as this sent our way: “Internet doesn’t work”
I mean, that’s really a software design issue. Like, the system should be set up to have a system log of those.
Most visual novel video game systems provide a history to review messages, if one accidentally skipped through something important.
Many traditional roguelikes have a message log to review for the same reason.
Many systems have a “show a modal alert dialog” API call, but don’t send it to a log, which frankly is a little bit bonkers; instead, they have separate alert and logging systems. I guess maybe you could make a privacy argument for that, not spreading state all over even the local system, but I’d think that it wouldn’t be that hard to make it more-obvious to the user how to clear the log.
Well, it might be a ‘software design issue’, but it’s really more of a branching point that was made long ago and reflects the world we live in. It could be fixed, but the point is that error messages are often not logged but people tend to act like they must be, and that their vague description of an issue should be enough to track it down like ‘something flashed on my screen last week’.
Hell people can’t even describe useful parts of an error that’s correctly happening…‘it’s not doing ANYTHING!’ can often mean anything from not booting, to the mouse not moving, to ‘it’s working perfectly but icons are snapping into place instead of staying exactly where I’m dragging them’.
This is usually coupled with the expectation that I’m going to use some special knowledge to do it rather than just pasting the contents of the error message into a web search and following the simple instructions contained in the first link.
This grinds my gears super hard. I’ve had a few new hires come through and they can’t do anything unless someone tells them to do something or if its written out step by step. Absolutely no critical thinking, curiosity or even basic understanding of why we’re doing what we’re doing, the job might as well be severance lol. I have no idea whats going on, they interviewed well, had relevant experience and can do the basics but as soon as we have to troubleshoot or use our brains they just go dear in the headlights. Its something thats difficult to train.
I’m trying to work things out but I swear its a generational “kids these days” thing. Its a science field with lots of interpretation, judgement, problem solving and troubleshooting too so critical thinking is really important.
I used to work as a refrigeration technician and when I first started I was working with an old Russian dude who had no filter. We’d walk into a store and he’d ask the owner “ok so what’s the problem?” and if they ever said “the machine isn’t working.” he’d immediately reply with “no shit man, I wouldn’t be here if it was working…” Lol
That drives me nuts sometimes. Like even professionals sometimes seem unable to do basic troubleshooting. I work in live music, I am not a tech/engineer but have done a lot of tech work on and around stages.
Simple stuff like - one speaker is not giving a signal, two techs are unable to identify the fault for over 20 min. I observe for a bit, they check the console, they check the speaker, they check the power supply.
And I, half joking, ask - have you switched sides already? Both look at me like they don’t understand my question, I walk over to the signal line for the PA, unplug them both, plug the left side into the right signal and vice versa on the other side - the problem moves from one speaker to the other, so it has to be a faulty cable. I was so baffled by that.
WHY IS THAT NOT THE FIRST THING YOU DO??? It takes seconds!
Or a wireless in-ear system has weird noises in the signal, I suggest to switch the frequency, the old tech grunts at me that he has already done that, I check and he moved the frequency like 10mhz. I suggest to move to a totally different frequency range and he gets rude so I go somewhere else. Half an hour later it turns out I was right. Why do you fuck around with firmware and shit before you do something simpler and quicker?
I might as well go first: Basic troubleshooting and reasoning.
I mean, we’re not talking debugging assembly language here. But at least you should be able to reply correctly to the question “is it dead or faulty?” when it comes to a computer. And when a your car has a weird noise, at least try to locate it for an obvious cause such as something rolling around under your seat.
EDIT: And one important aspect of troubleshooting many people don’t get is how to narrow down the problem. Let’s say your wifi isn’t working - have you checked on any other device whether it’s working there? Someone else mentioned binary search which has a lot of overlap with this.
“I don’t know what the error said, I clicked ok and it went away. Now fix it”.
Bingo.
I used to work with internet on trains, and the system was relatively simple by today’s standards. Not so much back then, but:
On other words, many potential points of failure. And sometimes we’d get tickets such as this sent our way: “Internet doesn’t work”
I mean, that’s really a software design issue. Like, the system should be set up to have a system log of those.
Most visual novel video game systems provide a history to review messages, if one accidentally skipped through something important.
Many traditional roguelikes have a message log to review for the same reason.
Many systems have a “show a modal alert dialog” API call, but don’t send it to a log, which frankly is a little bit bonkers; instead, they have separate alert and logging systems. I guess maybe you could make a privacy argument for that, not spreading state all over even the local system, but I’d think that it wouldn’t be that hard to make it more-obvious to the user how to clear the log.
Well, it might be a ‘software design issue’, but it’s really more of a branching point that was made long ago and reflects the world we live in. It could be fixed, but the point is that error messages are often not logged but people tend to act like they must be, and that their vague description of an issue should be enough to track it down like ‘something flashed on my screen last week’.
Hell people can’t even describe useful parts of an error that’s correctly happening…‘it’s not doing ANYTHING!’ can often mean anything from not booting, to the mouse not moving, to ‘it’s working perfectly but icons are snapping into place instead of staying exactly where I’m dragging them’.
This is usually coupled with the expectation that I’m going to use some special knowledge to do it rather than just pasting the contents of the error message into a web search and following the simple instructions contained in the first link.
Always a relevant XKCD.
https://xkcd.com/627/
You can apply this process to just about anything.
I had that stuck to my desk at work for years. And I haven’t even opened the link yet to see if it’s the one I think it is.
Yep, it was 😁
This grinds my gears super hard. I’ve had a few new hires come through and they can’t do anything unless someone tells them to do something or if its written out step by step. Absolutely no critical thinking, curiosity or even basic understanding of why we’re doing what we’re doing, the job might as well be severance lol. I have no idea whats going on, they interviewed well, had relevant experience and can do the basics but as soon as we have to troubleshoot or use our brains they just go dear in the headlights. Its something thats difficult to train.
Maybe they prefer the work to be mysterious (and important)
Maybe they got in trouble too many times for not doing it exactly as instructed, even if the instruction is obviously bullshit in some ways?
I’m trying to work things out but I swear its a generational “kids these days” thing. Its a science field with lots of interpretation, judgement, problem solving and troubleshooting too so critical thinking is really important.
I used to work as a refrigeration technician and when I first started I was working with an old Russian dude who had no filter. We’d walk into a store and he’d ask the owner “ok so what’s the problem?” and if they ever said “the machine isn’t working.” he’d immediately reply with “no shit man, I wouldn’t be here if it was working…” Lol
That drives me nuts sometimes. Like even professionals sometimes seem unable to do basic troubleshooting. I work in live music, I am not a tech/engineer but have done a lot of tech work on and around stages.
Simple stuff like - one speaker is not giving a signal, two techs are unable to identify the fault for over 20 min. I observe for a bit, they check the console, they check the speaker, they check the power supply.
And I, half joking, ask - have you switched sides already? Both look at me like they don’t understand my question, I walk over to the signal line for the PA, unplug them both, plug the left side into the right signal and vice versa on the other side - the problem moves from one speaker to the other, so it has to be a faulty cable. I was so baffled by that.
WHY IS THAT NOT THE FIRST THING YOU DO??? It takes seconds!
Or a wireless in-ear system has weird noises in the signal, I suggest to switch the frequency, the old tech grunts at me that he has already done that, I check and he moved the frequency like 10mhz. I suggest to move to a totally different frequency range and he gets rude so I go somewhere else. Half an hour later it turns out I was right. Why do you fuck around with firmware and shit before you do something simpler and quicker?