Admirable restraint on the part of "Mike"
I am not sure I would have been as patient as that.
I am sure Simon might have had a different solution, possibly involving a cattle prod.
Welcome once more to On Call, The Register's reader-contributed Friday column in which we share your stories of tech support jobs so wrong, they're right. This week, meet a reader we'll Regomize as "Mike," who told us about his time as a traveling engineer for a local education authority in the UK Midlands. The job meant Mike …
I educate and never let users get away with it, because that way leads to undeserved reputations of "IT expert" and even bigger problems in the future when they've " not got the time to sort it but I'm sure it will only take a few minutes" after they've spent hours making a complete balls of it and left a smouldering heap of crap for me to fix.
"Funnily enough, a lot of them were in upper management . . ."
TRUE upper management types are generally far too busy bending the company over a barrel to interact personally with IT; they have minions for that. In fact even their minions have minions. If you're on the Helldesk and somebody calls claiming to be UM, chances are they are a LOT lower on the slippery totem pole than they think they are and are hoping to "motivate" you with their job title. Which generally works as well as you would expect.
'The higher up you are in the company has no bearing on how fast your problem gets fixed; it just determines which floor we're on when I throw you out of the window'
Upper management tend to have Business grads assigned to them. So not only do these grads not really know what their boss wants fixing, they have no understanding of the labyrinthine corporate IT system which answers 'computer says no' to almost any question not submitted via the Vogons and you're lucky if it comes out the other side in the same shape. And always their question will be 'urgent' because they are tasked with making the boss' laptop work for an all-hands call that is due to start in 30 minutes. Said laptop hasn't worked for a while but UM were 'too busy' to engage with helldesk and get it fixed.
When a previous employer was subjected to what can only be referred to as a hostile takeover (at least from a staff perspective), there was a whole new management team installed. About a week later I was on helldesk duty when I got a call from our new CEO. ...'s husband. Who was clearly at home, on their personal computer, having problems with something he was trying to do, even though he SAID he was calling on behalf of his wife, who as he put it, was my new boss. I managed to sort him out after some back and forth; most of the issue stemmed from the fact that he thought the word "CANCEL" meant "CONCEAL", at least that's how he pronounced it - this was in a country where English was (at best) a second language.
After I recanted the story in our next team meeting, my boss could sense where things were going, so he decided that from that day on, we were to ask all helldesk callers for their asset tag (which was on a big blue sticker on every PC, clearly visible) before we could open a support ticket to work on, and that there was to be no work done whatsoever (not even a password reset) without a ticket. And yeah, sure enough, not six months later we were all outsourced.
At a previous gig, I was on a great team, we all had the "Take one for the Team Users". We all had one user that just made life difficult. We all knew who each other's pain user was, we would make sure that tickets for those pain users didn't land in the teammates lap. I also used to take most of the Minister of Finance's(aka Business Manager) tickets, I'll take one for the Team!!
At a former employer, the owner was himself multinational and frequently travelled to several countries around the world. He wanted one cell phone that would work everywhere (multiple SIMSs was OK). This was maybe 15 years ago, when GSM was supposedly the common denominator. However, try as he might, there was always some glitch...usually involving data, calls usually went through. SMS and even worse, email, was a repeating issue as the various carriers tried to "improve" their services. He was not happy when he couldn't access his inbox.
Our poor Finance person (this was a small company) who had fixed things for him once, was designated by him to be the resolver of difficulties. Since I sat near her desk, I would listen to her calling service providers in other countries, trying to determine why his plan wasn't working the way he thought it should. As GSM interoperability between national telecoms improved, her burden lightened, but I don't think she was ever free of the albatross he hung around her neck. Our IT folks sympathised with her, did all they could, but sometimes, "the bear gets you", and it's even worse when you have to deal with multiple "bears" who speak different languages (technical and marketing)).
I got into trouble, for suggesting to a user that, perhaps, they should write down the instructions. This was because I had had the same issue logged for 3 consecutive days.
I think it was "unable to access e-mail", but in their defence, it was back in the Windows 3.1 days, and the users had two mailboxes, one on an IBM mainframe, and another completely separate mailbox on a VMS system.
So, access was simple, you were getting used to this Windows 3.1 thingy an you had LAT running, so DECNET access was in place, but needed to manually start the Trumpet Winsock IP stack, then open the 3270 terminal emulator (Rumba) for the mainframe, or open WRQ Reflection for the VMX box. Once in the app, you then open the preconfigured session to access the remote host, then login to the server, then go to the mail app, then navigate the mail app to read or write your emails. Once you were done, follow the logout procedure.
Yes it was stupidly complex for ordinary users and a right pain in the a$$ to make everything work on the systems, but it worked and it had been rolled out by the powers that be. It then fell to the army of support people to keep it all up and running.
What I didn't understand as a young 20 something at the time, was that there was this thing called menopause and the meer act of suggesting that perhaps writing down the information would be a good idea, got a complaint filed against me. Luckily management saw the bigger picture and the lady in question actually apollogised to me a couple of weeks later.
The support days are good fun at the time, but you are sure happy to have them behind you, once you work your way up the ladder a bit.
Actually, I'm kinda in her court and wondering why you didn't have a little cheatsheet if things were that much of a barrel of shit.
The couple times I've dealt with the "oh yeah it's a pain, but it's far too expensive to change the mainframe" situation I've handed them a little half page step-by-step procedure and got a "OH THANK YOU!!!" and a grateful email to my manager. And usually it's the same cheatsheet I use, with the swearing removed.
It shouldn't have to fall to her to write it down, that's your job.
"It shouldn't have to fall to her to write it down, that's your job."
I'm not sure about that one. Sometimes it helps to learn. Perhaps produce an instruction list but also sit with the user who's having problems and walk it through with them suggesting it might help if they take notes.
Yeah, I show them my list, then get them to make their own as we go through it together. Three main reasons. First, not everyone's thing is structure and order, so showing my list gives an example. Second, they can use their style and jargon. Third, when learning, using multiple parts of the brain reinforces the learning process.
The second reason is really useful, as they know what they call things - it can break the ice too, as it can often be funny. "Oh, I've never known what that was, I just call it the 'doobrie-flip'" "So, write that down, but don't be surprised when others refer to it as a <insert user white noise>. Just put a little note next to it with its real name." They can also use their structure for their notes, in the way their brain connects the dots.
Taking this approach, there's rarely more than one follow-up call, for clarification - I can hear the greater confidence, and we're now speaking on a common level.
Reminds me of one of my more memorable moments in a consulting life long ago....
Estimated time to repair on a directory service that was very badly mangled - 20 hours.... to which the spreadsheet jockey who had somehow managed to end up the role of the client's Directory Services Manager replied with the above title.....
My practice manager who happened to be sitting in on the meeting had to ask me to step outside momentarily - "for the sake of the relationship". The fix was assigned to someone else - and yes - it took c. 20 hours of intensive effort to sort it out.
Not really a wrong diagnosis, but for some reason we always get the blame for absolutely everything if we visited a site in the past week or so.
"Hello, one of your employees was here yesterday for our phone, and now our internet doesn't work" (a DECT handset was replaced).
My colleague had an encounter that took the cake: He was at a site to install an IP door intercom. The hole to the outside was already there, but inside the building he drilled a small hole through a piece of drywall to get the cable to the network cabinet. He was finishing up when the building's janitor approached him:
"Hi, were you drilling just now?"
"Yes i was installing the door intercom"
"Well the toilets are clogged now"
"....okay?"
We put an internet connecting into a school, ISDN dialup.
We had 4 machines for the kids to use, one had a 4 port 10mbps network card to work as the hub, with 3 machines plugged into it with wingate as a proxy.
The 4th connection ran up the wall, along the corridor, to the admin office, so the staff machine could share it too.
1 week later the admin machine couldn't access the internet.
We got told by the head that it was our fault, the system was crap, etc.
I walked the cable run, and pointed out that our system would be working fine if the plumbers they had had in to work on the heating system hadn't blowtorched the cable as it ran along the wall/ceiling where the pipes were.
over 2 metres of charred cat5. But it was "our fault".
If said plumbers had burned through some mains cabling instead and turned the power off to half the building, or through an alarm cable and caused a fire evacuation, the results would have been immediate and the plumbers would have obviously got the blame.
Or maybe not; who knows? Some people see "cable installed by <n>, therefore problem caused by <n>" even if said installation was a decade ago.
M.
Sparkies get blamed for everything in the exact same manner
(it's why I no longer work for family as when I was sparkying in the past,.everytime something stopped working and totally unrelated stuff....it must have been something i did as "it was working before and it stopped not long after you finished" - trying to educate the quarter wits who make up most of my family was excessively wearisome)
I stopped doing fixes for mates for much the same reason, after the time one collared me in the pub with "JJ, we've got a problem with the computer. You know you stopped it making a noise last week" (the PSU fan was clogged with dust and cat hair) "well since then my wife hasn't been able to download her email, and it was obviously something you did as it started after you fixed the noise"
Some years ago a friend of mine who worked for the phone company was called out on a Monday morning to a small department store. That it was possible to profitably operate a small department store that didn't open on a Sunday should give you an idea of how long ago this was.
The customer complaint was that only the operator console was working, all extensions were inoperable. Having confirmed the fault he started tracing the cables from the PABX and this led him to a room with the distinct smell and appearance of brand new carpet. A 50-pair descended through the floor and re-appeared after an inch or two before continuing on its merry way. So he went downstairs, but no cable was visible. When he went back up and tugged on it... 'honestly officer, it just came off in my hands'.
Turned out that the carpet fitter had slashed the cable with his Stanley knife on the Sunday, so he did the obvious thing; he severed it properly, pulled up a little slack, drilled two holes in the floor and shoved the ends out of sight.
I may have said before but it is well known that you can supply, install, commission and hand-over multi-million pound project, leave it running smoothly with that satisfying, low 'hum' of rotating machines operating at peak efficiency, all operating on hair-trigger, precise control, signal-lights blinking gently giving complete reassurance of a job well done. The locked, secure, unmanned station is operating perfectly, confirmed by the data-transfer to the remote operations centre. The customer, his consultant and associated hangers-on are all enjoying dinner at our expense.
It's going to be a bad day for the contractor: There's a rattle from a piece of flooring, although this wasn't in your scope of supply.
...Like, many years ago, my favorite way to as ask the user questions. Very interested and curious and, um, leading questions. This usually had one of two outcomes: 1.) They would usually realize that there was something that they didn't get but still double down on the fact that they were right, or 2.) Rarely realize that I was trying to instruct them without giving eavesdropping subordinates ammunition to use against them. Then some fucking idiot wrote a book called "Windows95 for Dummies" and EVERYONE was an expert overnight. Except for those that realized they were not in fact dummies and were willing to admit it. If they owned their ignorance and were willing to correct it we got along just fine.
I make industrial automation software. These programs communicate with things that do stuff in the real world, and usually can't wait on the software except in limited, predefined moments. Their own programming also tends to be, ah, not terribly resilient when other bits have hiccups. Because of this, usually, the software I make is not supposed to be stopped except via a well-defined procedure, to be performed only in well-defined circumstances. Otherwise, all kinds of interesting fuckups can happen. If it happens, I'll deal with it, but I do my best to minimize such cases; for example, you can't close the program except via task manager/services or with a password.
Sometimes, I get a user who thinks himself smart because he knows that all kinds of IT problems can go away with a reboot. This kind of user reboots the PC at the first problem, which just compounds the problem instead of fixing it, and then calls me.
And then, there was that one user that did so repeatedly, even after getting told never to reboot without calling me. In one case, the program was showing him an alert stating that a sequence wasn't starting, and the SCADA by the side was telling him that an electrovalve was stuck - and guess what his solution was? On the plus side, I swore at him a lot, and he finally learned not to reboot without calling me.
Unfortunately the more effort you put into clean up procedures and initializing those system components that might otherwise cause issues after a restart the more likely it is the operators will just restart the server instead of investigating which component has an issue and fix the problem causing the system to fail.
It can get to the point where the customer starts complaining they have to reset the control software multiple times in a shift and it can't be another component failure as restarting the software always fixes the problem.
Turn it off and on again is done for a reason - most of the time it does fix the problem.
Even worse, the ones who think they can fix a problem by power cycling......... by flicking the power switch as fast as possible, the *SOLE* intention can *ONLY* be to destroy the ******ing power supply.
Seriously, what on *EARTH* causes somebody to think that the method of doing *ANYTHING* is to inturrupt the power for as short a time as possible? I first saw it in the early 1980s, and have seen it ever since.
Honestly I struggle to cope when people tell me things that I 'know' to be wrong, untrue and counterfactual. There's a part of my brain kicks in wanting to immediately and loudly correct them. I try to keep a lid on it these days because experience has slowly taught me that - even if it is only one time in ten - sometimes the buggers are _right_ and it's not a good look to be telling someone "that's nonsense, don't be silly, of course it's not XYZ" only to discover ten minutes later that it was, in fact a problem with XYZ.
I've learned that people don't react well to being told outright that they're wrong. I've become quite diplomatic with it. I'll often go with: "we have a saying in the IT world: trust, but verify. In the same way as an electrician will trust that you've turned the switch off but will still check that the circuit isn't live, I'd just like to confirm ..."
In the article's case that would probably be followed up with "the connection was loose at the other end, so was probably intermittent. I've re-terminated it so should be OK now" - gives them an element of them being right when we know that they were spewing bullshit.
I've learned that people don't react well to being told outright that they're wrong.
I discovered that early in my career, especially when dealing with people who were experts in their field but idiots with IT.
It's not that difficult, instead of saying, "You did X you *******" it's "Usually when that happens someone did X, I'm not saying you did so but it's possible".
Reminds me of my days in the early 1970s when I was an apprentice/trainee TV engineer for Rediffusion. I had accompanied an engineer called Mack to collect a rental TV that the customer no longer required. As the mains socket was the other side of the chimney breast, the customer had, at some point, extended the mains cable using the then still legal "taped joint" - i.e. twisting the wires together and wrapping the whole thing in insulating tape.
As the customer wanted to keep their section of wire they'd used to extend it, Mack said, "Fine. Please unplug the cable and I will just cut it with these (insulated, thank goodness) snips at the taped joint."
"It's unplugged," says the customer.
Snip - BANG!
"Oops," says the customer, "I think I may have unplugged the wrong cable."
Mack stands there in shock, staring at his snips, which, by this point, had a large, smoking hole blown out of the cutting edges.
> I realise 'attempted manslaughter' is a contradiction in terms, but sometimes, I do think there should be a place for it as a criminal charge.
Is a crime here. Specifically to Florida (I know FLA is not a real place but they have laws..)
What is Attempted Manslaughter? Leppard Law
It seems to be a federal charge too.
A safer version...
Customer has 2 modem lines and keeps reporting one faulty... it's never the modem/line
Engineer: "modem A works but B doesn't... swap the interface cables, now B works but A doesn't... where's the fault?"
Customer's 'IT' bod: "the modem?"
Our internet connection failed a few weeks ago - weather related - which got fixed fairly quickly but the tech ran through a series of tests. everything was working but he announced we had a split pair. Plugged his tester into the master socket after unplugging the modem cable and found the master to be OK. Confidently announced "It's your modem". Never stopped to think that a modem, identical to thousands of other mass-produced modems is unlikely to have been manufactured with an internal fault but --- the cable he'd just unplugged?
I've been a victim of the "unplugged" plug. I was 15 and setting up to do some soldering. The soldering iron wasn't heating. There was a connector block used to extend the cable, and I noticed the live was loose. So I unplugged... Yoiks!!! Sitting on my backside 3 metres away from the connector block, calling myself all the names under the Sun, I really learnt a lesson!
I suppose that switching off the whole house electricity supply before cutting that cable could be, um, overkill.
I'm not a professional electrician but I think I'd want to have the plug lying next to my feet - safely - before I cut the cable that the plug supplied 240 volts AC into.
Yes, cables with a mains plug at both ends are a thing. A terrible thing. A very unwise thing.
We had a problem on an important site and the customer's 'Engineer' was an ex-colleague from a long time back. He was not technical in any way but would loudly pronounce on any electrical/mechanical/electronic issue with absolute authority and conviction. He could and did waste a lot of money solving the wrong problem.
This site had an issue that he decided was caused by an obscure phenomenon, often talked about but rarely encountered in modern times. The more likely solution was far simpler and easily sorted. In the office, we all had a good laugh at this idiot's expense before I was dispatched to investigate.
From long experience.... I know to listen carefully and investigate problems in a logical sequence, rather than arrive and state our presumed answer to the issue. On this occasion, I was fortunate to keep my powder dry, the self-proclaimed genius had indeed identified the correct issue and this was going to be an expensive incident. Not exposing his technical weaknesses, we maintained a good working relationship to correct the problem and our liabilities and expense were minimised.
Infuriatingly, sometimes, these people hit upon the right answer.
I was called out to fix the IP phone in a gas station kiosk. The attendant said that it goes out mostly on rainy days in the spring and summer. The station is located around the corner and a block away from its parent grocery store. I took a walk outside and saw that there was a microwave antenna on the gas station canopy, and another on a mast on the roof of the main store. When installed, it would have had a clear line of sight over the roof of the 1-story strip shopping center that occupies the corner lot. Problem was that a hotel had been built, diagonally in from the strip mall. When the saplings that originally adorned the hotel's parking lot and sidewalks had begun to grow into proper trees, the leafy green microwave absorbers began to block the path . . . especially on rainy days in the spring and summer.
I wasn't able to mitigate their circumstance that day, but listening to the user's description of the symptoms pointed me toward the diagnosis. I haven't been back to the site since, so I don't know how they remedied it -- a buried fiber optic cable, a separate ISP connection to the gas station, or some other fix such as a passive repeater that would have been line-of-sight to both ends of the microwave link.
Just now, another possible remedy comes to mind -- replace the trees with bonsai??
Yeah, my favourite was my neighbour who insisted that the terrestrial TV had gone to fuck because our predecessor had installed $ky. Which had an entirely separate cable run. My repeated explanations that this was impossible since the frequencies and reception methodologies were different fell on deaf ears, so I'm afraid I had to resort to pointing out that I had nearly 60 years of electronics and RF experience, including an electrical engineering degree from one of the world's top 10 universities.
Still didn't believe me.
Or the other way around, elderly relative for reasons I won't bore you with had to replace a proper Copper landline with a flippin' BT hub etc. Almost as elderly TV set (not DVBT2 capable, certainly not "smart") running from terrestrial via a slightly dodgy booster the local "expert" had installed (to be fair the booster wasn't dodgy; it was his connections as I discovered some weeks later) constantly losing signal. Phone line goes live and the next day, slightly clued-up carer realises TV isn't working and "fiddles" with said booster and cables.
Elderly relative delighted to get TV back, claims it is the best picture ever and the carer agrees this must be because of the fibre broadband connection which has just been installed (and is not doing anything because all relative wants is a working big-button phone).
M.
In fairness, I've seen a huge number of "x hasn't worked since y was installed" when x and y are completely unrelated pieces of kit... that turns out to be that when the engineer installed y they dislodged a cable that goes to x, or generates RF interference, or blocks a signal.
You can declare it unlikely and it can be technically/logically impossible, but never rule it out until you've confirmed it.
Here we have the classic example of the God mentality. I know all, understand all, shape young minds... How dare the IT person know more than me and use this dark art called troubleshooting to find the source of my issue.
To be fair not all Teachers/Lecturers/Academics are like this but there I think there is a sizeable amount and a little knowledge is a dangerous thing.
Conversely with our first child many years ago my wife (a teacher) who was having a few problems "progressing" with the birth was told by the hospital midwife that "nurses and teachers are always the worst because they've read the books and won't listen to us". This attitude, summed up earlier that day by a different midwife refusing to listen to my wife who said "baby is not ready to come", insisted on medical intervention and justified it by saying "do you want your baby to die?", resulted in a traumatic experience which needn't have happened. Both sides of the family have a history of "late" babies (that is, babies born two weeks or more late), including a close relative who was born nearly four weeks late (and perfectly healthy), in the days when medics weren't quite as litigation-cautious. For our subsequent children my wife "lied" about dates, giving herself at least a week extra time, and all those children were born well within two weeks of the calculated due date (i.e. between two and three weeks "late" if the "real" dates had been used), and before any medical intervention had been forced on us.
Experts do not always know best - or maybe they do, but they often can't or won't see the bigger picture.
"Nurses make the worst patients". I was born on the maternity ward where my mum had been the ward sister until 3 weeks before she went into labour. After 22 hours of labour at 4am the consultant decided he wanted to go home so I was borm by cesaerian section.
I'll concede "my" or "our" baby, but not "the", particularly in a maternity ward where there are dozens of the things.
In common with lots of people, our unborn children had nicknames, but you don't use those outside the family. We also had a selection of "proper" names ready but nothing was decided until first breath was taken and first screams heard.
The point of the story though (and a couple of others I could recount regarding #1 offspring) was that quite often, mum knows best.
Working to support our military on various sites in the south and west country 1997-2001, (UK) this type of thing was common especially the Civvies who always would use the usualbut i can do this on my pc faster at home. or it worked earlier (to find it hadnt worked for weeks due to the user being on excercise for three months) and thier account was locked out for password in activity.
Though the favourite was the cleaners unplugging PCs to use the hoover and not plug them back in
I just remember the graveyards a full of people who were the full bottle on self diagnosis and as a consequence earnt an early mark.
I will be honest and say most of the people who have been enthusiastic in offering diagnoses had in the past been victim to piss poor support from the cattle wrangling fraternity who would abandon them to their predicament if an obvious, simple solution wasn't quickly evident.
Once you have "trained" them to trust a solution will be provided—period—they are more likely to give a description of the problem as they see it instead of their conjectured solution to their view of the problem. Compounding the felony their solution is often recast as a description which to the novice support both very misleading and confusing.
The best client is the one who doesn't know a bean about IT, doesn't want to, and for the trifecta, is devoid of imagination. Saves a lot of time.
>How do you handle users who push back with nonsense diagnoses?<
Only way to handle that is to ask them to tell what actually happened and what they expect the system to do instead if it worked properly and do your own diagnosis based on that.
Occasionally the uses diagnosis is correct but there are more cases where there is no problem but the user expects the system to do things it was never designed to do.
Ah yes, those who won't say what the problem actually is, only their idea of what needs to be fixed.
My favourite, and a favourite of my late mother, is "a message popped up and I clicked OK". I ask what the message said - and they can't tell me because they didn't read it before getting rid of it.
And a business partner from many years ago - and bear in mind we did IT services ... The accounts package we used had various forms (such as invoices) set up - and of course the set-up included page size. IIRC it was some time after I'd left the business, and he was using a different printer - OK, I imagine most of you are ahead on this one. So every time he came to print, it popped up a message that the page size didn't match - and his reaction was to cancel the print (might have been "hit enter, which on a normal print dialog was 'OK', but in this dialog was 'Cancel'), and then complain that the [expletive] software was [expletive] and didn't print stuff when he told it to and he had to keep reprinting stuff. He was that used to clicking Print and just hitting the enter key to do it, that he didn't bother reading the message that would have told him what the problem was, and given him the option of printing even though there was a page size mis-match.
Reminds me of that experiment where users agreed to handing over their firstborn when signing up. I've "surprised" a number of people when I've insisted on actually reading contracts (and sometimes, photographing them if I wasn't getting a copy) before signing.
I've had cases like that, as I grew older I tried (usually succesfully) variants of the theme
Oh yeah, this is a typical microsoft thing, see, the error message makes it looks like your mailbox is full, this happens a lot, whereas actaully what the error message means is that the printer is out of paper. These messages confuses a lot of people .. I mean, printer is out of paper is such a vague message ..... it could mean anything
Or
Ah, yes, you thught the printer was out pf paper, and that's why you couldn't print ... yes, too many popups, yeah, I used to just click them away too .. but sometimes they may be helpful, like if you get 20 popups that say `` no network detected'' that could mean that there is no network, so let's have a look at the back of the computer ...
ah you move dit a bit, so you could put your feet under your desk ... yeah, ... i complained about that to manintenance as well ... they should have put the computers more to the left .... yeah ... see this little white cable that's now lying on the floor ? ... yeah, bloody beancounters, we asked for 10m cables, but they only had budget for 5m cables ... yeah .. so if we just move the box back a little, and then put this white cable back in ... see ... yeah .. it's printing again ... yeah, so let me just take these 500pages of blank paper you alreayd put on your desk for me to put in the printer, and i'll take them back to supllies ...
The most incomprehensible message I ever got was on the LCD screen of a fax machine .
After much googling and PDF user manual crawling I finally deciphered it :
"out of paper"
This was leagues more cryptic than the old "PC Load Letter" , it may well have been in hex.
I had a colleague once that was adamant that "PC Load Letter" meant that the printer didn't support the font she'd used (because fonts are letters) and that you'd have to install (load) it into the printer somehow. She couldn't understand why IT would install fonts on your PCs that you couldn't print. Most printers allow you to bypass the Letter paper prompt and print on the standard A4 if you just pressed the big green button. Which she did every time. And then said "Huh, this actually looks pretty close to the font I used anyway."
@flightmode
Forty-five years ago, the boss typesetting unit was the Linotronic 202. The font definitions were on an 8.5" floppy disk, which would hold eighteen of them. (Probably because the last of the units that used film negatives had three drums of six negatives each.) The 202 made a clack-clack sound that I suppose was the heads seeking here and there, and I believe that it had a signal to indicate that a font was not found.
So perhaps your colleague had some experience of the old 202 days and supposed things were still that way. But she does sound to have been unduly stubborn.
This was in the early nineties, so it’s not too long after the era you’re describing (wait, that can’t be right… right?). We were in an adjacent area of business (several of our customers were print shops); so it’s possible someone else had explained this to her, but I’m pretty sure she wouldn’t have had the experience herself. We were in logistics and inventory planning and she was too young to have had another career before that job.
Interesting history lesson, though; thanks!
In one case I got a call from one of the managers (actually, she was quite a nice person and a decent manager, so naturally was one of the first to go when the business was having cashflow problems) ... "my terminal session isn't working" (we used terminal emulation software over Telnet, yes it was a long time ago) onto the main system. I walked down to her office to find ...
... a visitor needed internet access so she'd left him her ethernet cable. I politely pointed out that she had unplugged her computer, and she immediately realised (with a bit of embarrassment) her error.
I've often found the main sources of pain to be the Phd holders....such things like "oh, I wanted to make sure the button worked so I pressed harder and now it doesn't" or "I locked the robots joints up using console commands and twisted them to see what would happen, now it doesn't power up"
Admittedly some of them are genuinely lovely people who do their best not to break stuff and ask first before trying.
Then you get the know-it-all arseholes who are very intelligent, yet very stupid.
"oh, I wanted to make sure the button worked so I pressed harder and now it doesn't"
Well, with user interfaces now having no feedback, either mechanical or visual, that a none-response from the equipment is an explicit instruction to the user that the user hasn't pressed the button properly and that the user should try again and again and again and again and again and again and again and again. It's not the user, it's the fuckwit moron user interface designers.
Example: got a new microwave. Tried to do a test cook. Pressed the minute button. Nothing. Pressed again. Nothing. Pressed harder. Nothing. Pressed as hard as I fucking could, almost breaking my finger. Nothing. Clearly the fucking stupid machine is broken.
Went to open the door to take the food out, and brushed against the 'clock set' button. The fucking thing started working.
WHY THE FICK DOES THE FUCKIMNG CLOCK HAVE TO BE FUCKING SET BEFOPRE THE FUCKING THING WILL EVEN RESPOND????????
Most of the well-known brands of electric fan oven will not turn on at all unless the clock is set.
If I'm being extremely charitable I might guess that this is a misguided attempt to prevent the oven from turning on unexpectedly after a power cut.
More likely, it's a bug in the barely tested 97 cent control module they all use.
My favourite from the early 2000s:
A message was sent round to all users saying that the network would be down for about an hour on a particular day to allow for some routine maintenance (IIRC replacing a flaky hub that lived in a cupboard and was prone to overheating).
Cue multiple phone calls "I can't get on the network", etc etc
In fact the contractors had the replacement up and working in 45 minutes but it didn't stop the bleating.
I used to contract about 185 miles from home. Traffic on a Monday was not fun, so I used to set off very early and arrive at about 07:00.
I got in as usual one Monday, tried to login, and was greeted with a "You must change your password" dialog box that could only be dismissed either by cancelling or by changing the password. I obviously went with the second option, but all attempts to login after that were greeted with "Incorrect Password".
The hell desk didn't open until 08:30, so I happily spent the next (billable) 90 minutes drinking coffee and catching up on some reading.
At 08:30 I called the hell team, who asked if I had read the email they sent out the previous Friday instructing people to "cancel" the change notification as the login would still complete, and to then change the password from within Windows. Trouble with that was I was never in on a Friday and most people would have finished before the email was sent.
Their line was busy for quite a while that day.
Way back in the mid to late 80's I was running an upgrade to VMS on a Vax 11/780. We'd warned the users that the system would be down for several hours and to not try logging in.
The system rebooted 3 or 4 times during the upgrade, coming up with logins reenabled, and every single time before I managed to disable logins again someone had managed to jump on. They must have been sitting their constantly hitting enter on their terminals until they got a login prompt. Ideally we'd have isolated the machine but with multiple serial connections it wasn't that simple.
Later we managed to get DEC to confirm how we could stop this happening, it was in the manuals but given they filled a bookcase we'd never figured it out and they didn't bother to include it in the upgrade procedure.
Unfortunately it wasn't quite that simple - it was a large* multi-building site with multiple muxes and had connections to other sites as well. As we didn't "own" the cabling (it was installed and managed by another department) we didn't know what could or couldn't be safely unplugged.
*It was only a year or so before I arrived that they'd actually got 4800bps serial across the whole site, until then users at the outer extremities had to dial in over the internal phone system with 300bps modems!
I feel your pain
Several work hats ago I managed a SCO OpenServer system. We had the same problem, doing a call out for people to log off so we could do some maintenance - but before we'd got people out, sothers would be logging back in. But at least with this being a unix system, it was easy to modify the login script to check for a flag file and kick people straight back out again if it was there*.
* Actually, it would cat the contents of the file to the screen, then wait, then kick them out - that way we could leave a message for why they weren't able to log in right now.
On SCO systems,
Step 1. Edit the Message of the Day to warn people the system will be down for maintenance from X to Y.
Step 2. 10 minutes in advance, log in as root and use wall to warn of impending shutdown.
Step 3. At shutdown time, at the system console, log in as root and use init (or telinit) to switch to single-user mode.
Step 4. As root, copy /etc/inittab to /etc/inittab.save
Step 5. As root, edit /etc/inittab to remove the non-console device entries and save.
Step 6. Do your maintenance, going into multi-user mode or/and rebooting as neccessary.
Step 7. As root, move /etc/inittab.save back to /etc/inittab
Step 8. As root, use init (or telinit) with the "q" option to re-enter multiuser mode.
Step 2. 10 minutes in advance, log in as root and use wall to warn of impending shutdown.
Which unfortunately would well and truly screw up the screens of all users due to the way the software drew stuff
Step 3. At shutdown time, at the system console, log in as root and use init (or telinit) to switch to single-user mode.
Which would stop us doing the work we needed to do - we needed things like the database running in order to do much of our maintenance
It could also corrupt data by unceremoneously killing users who could be in the middle of tasks.
We'd do a broadcast via the phone system telling people to log out, then monitor, chase people who hadn't, and then manually kill processes - we could apply a bit of knowledge to see which could be killed safely ("ps" shows they are at a menu rather than in a module), and phone users who were in something that corrupt data if killed.
Step 5. As root, edit /etc/inittab to remove the non-console device entries and save.
Weeell, we had a few real serial ports, something like 256 rtelnet ports, and (from memory) 128 serial ports on an I/O system who's name I don't recall, but it used a Transputer in each 16 port serial box, and any mesh of 10mbps links between them (4 ports/box) and the host I/F card. That's a lot of ports to disable !
Our system of having the login script check for the existence of a file - and if it exists, cat the file to the terminal and give the user time to see it before logging them out again worked well for us. Also MUCH safer than the steps you've suggested - don't forget, I was the only "unix nerd", the others were more like power users than admins. We actually had two files - one to prevent logins altogether, and another that would stop access to the business software - some users used other software that could be used while we were "fixing" problems with the main business package.
I'll address your specific points first, then your more-general ones.
Step 2 ... screws up screens
Well-written screen-oriented software has a screen-redraw key or key sequence. In emacs Control-L redraws your screen. In vi, Control-L redraws your screen. In pdmenu, Control-L redraws your screen...
For simple character-stream apps outputting to the screen and nowhere else, you have to re-run whatever it was.
Step 5 ... that's a lot of ports
That should not matter, because the entry for the console device is near the top of the file. Move the line pointer (in vi or ed) BELOW the console entry, then do a .,$d and save the file.
Step 3/General Points - need database running, possible data corruption, chasing still-logged-in users.
• The switch to single-user mode in step 3 is log the users out gracefully. You can switch back to multiuser mode (and restart your database engines) if needed for maintenance -- users just won't be able to log in from their terminals/terminal emulator sessions during maintenance.
• Shutdown sends processes SIGTERM, which tells those processes to clean up and gracefully exit. If, after time-delay X, those processes are still running, the kernel hard-kills them.
The process I described in my original post presumed reasonably-thoughtful users and programmers.
What you ought to do and what you can do depends on:
* Management expectation/enforcement of end-user thoughtfulness and computer knowledge, and their response to IT staff in response to a user complaining, "Those bad IT people ruined my long-running data analysis! I never saw the message of the day announcing the down time because I never log out; I'm too busy to look at my emails or listen to my voicemails, and anyway, I started my analysis run, locked my terminal, and went on my three-month sabbatical."
* Acceptance of "stupid" software (note that just because the database is undamaged does not mean that the data within that database is logically-consistent. Both the DB engine and the apps which use it all have to be "smart").
* Number, nature, and geographical distribution of users.
I worked at a place with two data centers (mainframe and minicomputers), two server farms, at least one file server physically located in each building, 50+ IBM 3278 terminals, 2,000+ printers, 13,000+ PCs/workstations/other-devices (electron microscopes, microarray DNA scanner, drug- and medical-supply-dispensing boxes, ...), a shedload of those PCs being shared among nurses, doctors, medlab staff, and researchers, all distributed over a wide metro area with about 30 main campus buildings and another 30~40 satellite buildings.
It was the anti-thesis of one terminal/phone/office per user. "Chasing down" an individual user was a crap-shoot using the house's loaded dice.
Well-written screen-oriented software has a screen-redraw key or key sequence
Still inflicting issues on users which are avoidable. And assumes well written software ! Don't forget that "assume" makes an "ass" out of "u" and "me".
The switch to single-user mode in step 3 is log the users out gracefully. ... If, after time-delay X, those processes are still running, the kernel hard-kills them
Again, assumes well written software. If the software doesn't kick the user out mid-task, then the system just kills the session.
That should not matter, because the entry for the console device is near the top of the file. Move the line pointer (in vi or ed) BELOW the console entry, then do a .,$d and save the file
Seriously ? You want to get "not all that technical" people to play around with critical system files - v.s. giving them a safe alternative ?
Clearly we've been working on different systems (at different scales), but the fundamental issues are the same. We too had users who were hard to get hold of, but at the end of the day, it's unix and that means we get to choose how we do things (we chose what worked for us, and was fairly safe) - unlike some systems these days where these things aren't an option.
Oh yes, mostly we'd have a need for as-hoc maintenance using our methods. We did have planned maintenance, but the software was ... "interesting" ... and we'd often have to kick everyone out to fix something in the database :-( Or just to find out which users had got into a mutual conflicting record lock situation - e.g. user A is doing a task that locks records 1 & 2 (but has only got record 1 locked so far), user B is doing something that locks records 2 & 3 (but has only got record 2 locked so far), user C is doing something that's locked record 3 and now wants to lock records 1 & 2 but can't until user A and B have finished (and released their locks), but they can't until C has finished (and released it's locks.) None of them can continue until an admin (i.e. us) could decide which process should be killed.
Yes, it was "interesting" software.
We had application software written for a 80 x 24 character ANSI terminal. We actually used 80 x 25 terminal emulation on PCs, so we had a spare bottom line. I think also the ANSI emulation included saving and restoring the cursor location, so it was possible to save the cursor location on the terminal, write a message on terminal line 25, and then restore the cursor, in theory without disturbing the user's work - though not with "wall". I think I had a script called "line25" which did it to one user - probably pinged the terminal bell too?
It's not just the idiots with their nonsense diagnoses, they are also poisoning the well for when folks like us need to call a support line. They are conditioning helldesks everywhere to just lump our (somewhat) more credible analyses in with that lot. Like trying to find a story that's not written by AI on youtube.
If they're pushing back because "ChatGPT said..."
then I'll publicly humiliate them, and make a manager decide whether I'll be wasting a couple weeks on what chatgpt said, or a few hours or a day on what I decide is the correct path of action.
If not ChatGPT, then an ounce of understanding goes a long way. It might be a little embarrassing to the end user, but showing them your reasoning (the network light should come on) will give them information - and this user was showing that they love information! "Here's the information on why I believe-- oh, hrm." Anyway, it's not insulting to inform someone, and quite generally they take it very well -- so I try and give them all the information I use to make my diagnosis.
If they *still* don't believe me, and they're not using ChatGPT, then I'll typically follow it up with a "Trust me, this is why I'm here. I'm not perfect, but let me give it a try and we'll follow up for better or fail. It won't take long." This one, in those cases, hasn't failed me, so I don't have a recourse yet if it does. Probably, if things didn't take more than half a day, I'd do what they ask, and we'd see where it gets us (I mention to the network guys as I'm running between those tasks that the port is out, and eventually they get it working, and "Hey presto! What you said worked! Glad things are working now, lets follow up again if anything goes awry. :-D")
Phone call from a customer (when that was still a thing) to a colleague where said customer started with 'hello it is the pest again', to which the colleagure replied 'hello XXXXX, what is wrong?'. Obviously the correct answer would have been 'who is this, sorry?' which would have made the ensuing conversation less frosty.
In the days when telephone conversation was the norm, we had a customer who had a very pronounced stammer. On answering the phone, our switchboard would quickly recognise the caller and transfer him through to the Service Department without comment. We all knew him and after hearing a hesitation we would say "Hello, Jack. What can we do for you?" He immediately relaxed and a normal conversation could start.
We did a lot of good business through him. He was an Engineer and a Gentleman.
I spent a few years working at a boarding school.
One of the House Masters had a particular hatred for Chrome, so we regularly got calls to rid his computer of the browser, which would reappear whenever his computer was reimaged, which was often as he was forever breaking things.
Our Chrome removal services were also required for personal devices.
I didn't mind these jobs, as they were easy, and the chef in that boarding house was always happy to provide me with lunch and a couple of bags of good coffee for the office coffee machine.
Anyway, one day I get the call to go over there to rid his daughter's new laptop of Chrome, so I wondered over with thoughts of a hearty lunch and a couple of bags of Taylor's finest on my mind.
That is, until I caught sight of the laptop:
Anyone know how to remove Chrome from a Chromebook?
It was quite a few years ago when I needed the answer to that question but, at the time, it was "Yes, but the allowable distros and the method of installation will depend hugely on the precise model of Chromebook.".
I had an ARM based Chromebook (basically a phone with a keyboard and a 13" HD display) and I could install Arch on it. Nothing else, unless I fancied learning an awful lot about potting Linux to new platforms. Arch was fun though and (aside from not really using the GPU to the full) worked fine.
(Very similar to "Can I change the OS on my phone?" in more recent times, and utterly different to "Can I change the OS on my PC?" which, thanks to Microsoft's decades of bullying is, trivially, "Yes, of course!".)
In Android at least, you can install the browser of choice, disable Chrome (settings>apps) and replace the Chrome shortcut on the quick launch toolbar with one for the browser. Playstore keeps installing updates but Chrome doesn't appear to try to phone home at any point, although components possibly do (I've got a no-root firewall installed and it doesn't flag up any connections)
Had the opposite problem once.
Cabled a place that had a very fussy and self-important manager who had one of those "fishbowl" offices with blinds built into the glazed units.
On completion, he pointed out that there was supposed to be a network port in his office, despite his not having a machine.
"Yes. There it is." says I, pointing at it.
"Don't give me that, it's not connected."
"Yes it is. If you like we can get something to plug in to prove it!".
"Look, I can clearly see that there's no cable running to it. I'm not being taken in by any tricks like that.".
"Ah, right. If you look at your glazed wall units here, you can see a recessed joint between each. This one appears is flush instead, which is where the mini trunking runs down from the ceiling with the cable in it.".
He studied this for a minute: "Yeees, I see now. That's invisible, unless you know what you're looking for. Right then, that's everything.".
With the benefit of hindsight, we should have asked for more money for "invisible" installations.
"Mike decided the best way to support the teacher was to leave him alone."
I think I'd have told him that if the problem was too much stuff in the inbox or on the PC I could leave it to him to clear some space - he'd have to do it himself as only he knew what had to be kept. And then reply to the follow-up calls telling him that he needed to delete more stuff.
Having worked in Support for several decades, it's the only way to deal with know-it-alls. I had one start on me when I walked out of his office and I told him straight to his face that since he knew it all already he didn't need my expertise. He then tried to badmouth me with my boss and with the company CEO, both of whom knew better. Several hours later he asked me politely if I would help him with his problem and in 15 mins it was fixed. The twat never apologised and from then on we stayed away from each other. I am not perfect and I do occasionally make mistakes, but I will not put up with that kind of treatment from anyone.
The keyword "education" brought back a flood of memories.
I supported an educational arm at one point.
Their personnel were given access to the network closet to maintain their novell server.
About once a week we had complaints about the network being down.
The "education" crew was always at fault for overstepping their bounds and disconnecting
ports, switches and telephone lines.
Finally my director had enough and put up a chain link fence in the network closet
between our network/telecomm gear and their server.
The closet fortunately had two doors for entry and the lock for our side was re-keyed
late one evening.
They were furious and of course, we had no further "network down" cries from them further.
In my brief time in tech support, I encountered so many people with such attitudes. I would always think; "Why did you call?". As much as I enjoy computers and technology, In retrospect I am glad that my IT career never took off. I don't have any tolerance for enduring such treatment from people who call me for help.