Dear Users… (A thread for Sysadmin, Technical Support, and Help Desk people) Part 10

Status
Not open for further replies.
So I just had my ear chewed off by The Most Important Person In The Department because I couldn't reset the password on a system that we don't own or manage.

Things I've been asked to reset, and gotten at least some degree of huffiness or attitude when unable to do so, in the last year:

- Personally owned phone password/pins.
- Personal Gmail/Yahoo/etc e-mail accounts.
- Passwords to multiple external hospital/vendor websites.
- The Bluetooth PIN on the infotainment system on someone's car.
 
Things I've been asked to reset, and gotten at least some degree of huffiness or attitude when unable to do so, in the last year:

- Personally owned phone password/pins.
- Personal Gmail/Yahoo/etc e-mail accounts.
- Passwords to multiple external hospital/vendor websites.
- The Bluetooth PIN on the infotainment system on someone's car.

A company I did the IT support for had one of the owners leave the company several years ago. Among other things, I forwarded his company email to one of the remaining owners.

About three years later the former owner emailed me from an email at the company he had moved to and asked me to forward his email to yet another company, neither of which I had any connection with or access to. I tried to make him understand I couldn't make any changes to the email for either of those companies. He seemed somewhat miffed I wouldn't help him.
 
Things I've been asked to reset, and gotten at least some degree of huffiness or attitude when unable to do so, in the last year:

- Personally owned phone password/pins.
- Personal Gmail/Yahoo/etc e-mail accounts.
- Passwords to multiple external hospital/vendor websites.
- The Bluetooth PIN on the infotainment system on someone's car.

Have heard a MD demand of her programmers that they need to hack her phone because she'd forgotten her password. Turned out it wasn't even a password for the phone but a password for her Virgin Atlantic account, and she'd failed the security back-up questions so the account was locked until it could be verified with the likes of her passport etc. So she was demanding that someone hack Virgin Atlantic systems...
 
Moore's law implies that computing power doubles in eighteen months, not by a factor of 600,000 in a year.
No it doesn't. It just states the number of transistors in a chip will double. Hence the reason that computer performance hasn't actually improved without prior going to the trouble of writing parallel processing. Chick speed has been stagnant for years.
 
No it doesn't. It just states the number of transistors in a chip will double. Hence the reason that computer performance hasn't actually improved without prior going to the trouble of writing parallel processing. Chick speed has been stagnant for years.
You are of course correct, though the additional transistors allow more processing cores and hence more computing power.

Also your typo is hilarious, auto-correct? I could make a comment....
 
No it doesn't. It just states the number of transistors in a chip will double. Hence the reason that computer performance hasn't actually improved without prior going to the trouble of writing parallel processing. Chick speed has been stagnant for years.

You are of course correct, though the additional transistors allow more processing cores and hence more computing power.

Also your typo is hilarious, auto-correct? I could make a comment....
We have all gotten older and wrinklier with the years, alas. Chicks dig guys with hair.
 
We had another developer fulfil the stereotype today. They were having a problem installing a particular version of a software library, and they asked us to add an "uninstall" button to the installer so that they could fix the problem by reverting to an earlier version.

This illustrates two things about this particular stereotype. First, they love to tell us how they want us to fix their problem while failing to understand "it doesn't work that way". Second, they're a developer. They think we should just be able to inject some code to make it work that way.

It doesn't work that way? Why doesn't it work that way? It should work that way. I bet I could make it work that way. That's not my job. You do it.

How about you tell us what your problem is, and we'll determine the most appropriate way to fix it? That is, after all, our job.
 
We had another developer fulfil the stereotype today. They were having a problem installing a particular version of a software library, and they asked us to add an "uninstall" button to the installer so that they could fix the problem by reverting to an earlier version.

This illustrates two things about this particular stereotype. First, they love to tell us how they want us to fix their problem while failing to understand "it doesn't work that way". Second, they're a developer. They think we should just be able to inject some code to make it work that way.

It doesn't work that way? Why doesn't it work that way? It should work that way. I bet I could make it work that way. That's not my job. You do it.

How about you tell us what your problem is, and we'll determine the most appropriate way to fix it? That is, after all, our job.

I do have to ask - "developer" in what sense? I can't believe a programmer would come up with something so patently unrealistic?
 
I do have to ask - "developer" in what sense? I can't believe a programmer would come up with something so patently unrealistic?
Probably SQL or Azure, since they're what the department makes most heavy use of right now. Maybe Visual Studio. I've seen requests for Python and C++ libraries come through the queue. Not being any kind of developer myself, I can't really say that I have any idea what they're doing. :)
 
We had another developer fulfil the stereotype today. They were having a problem installing a particular version of a software library, and they asked us to add an "uninstall" button to the installer so that they could fix the problem by reverting to an earlier version.

This illustrates two things about this particular stereotype. First, they love to tell us how they want us to fix their problem while failing to understand "it doesn't work that way". Second, they're a developer. They think we should just be able to inject some code to make it work that way.

It doesn't work that way? Why doesn't it work that way? It should work that way. I bet I could make it work that way. That's not my job. You do it.

How about you tell us what your problem is, and we'll determine the most appropriate way to fix it? That is, after all, our job.

While it's hard to know without knowing the exact library and versions, some versions do have known bugs and even critical exploits. Expecting that someone should waste client time and money fixing bugs in third party libraries because they're a developer is stupid beyond belief and one of the reason why some devs have... shall we say... negative sterotypes about admins just trying to pass the buck and not do their flippin' job.

Honestly, if you automatically install it on my system (and that goes for production and QA machines too), it's YOUR job. Trying to pass the buck to me just because I'm a dev, just tells me you're both lazy and too stupid to be in that job in the first place. Just because I'm a dev, doesn't mean I know the inner workings of every library on the internet, and how to work around the critical exploit that just popped up on nvd.nist.gov or whatever. I'm not the one who wrote, say, the Java libraries or Log4J. Nor is it a good use of my time and the client's money to debug and brainstorm and find a workaround, when another version already fixed that or doesn't have the exploit yet. Or even just didn't change its behaviour from what it was when we were writing the app. It's an idiotically unreasonable expectation that I debug and figure out a workaround THAT -- and doubly so for apps that are just on life support and no longer have either the team or the budget for any such changes -- just so you can play with your dick instead of doing your flippin' job.

Briefly: if you insist on being the one installing crap on my system, yes, it is YOUR damn job to provide whatever version my program needs to do its job well and securely. You don't need to find idiotic excuses. You don't even need to know why. Just do your damn job instead of finding self-serving rationalizations as to why it's wrong to ask you to do what's in your job description. If the app X needs library Y in version Z, then do your job and provide that. You may point out that version Z1 doesn't have some other bug, or is needed by something else on the system, but that's really it. Anything else is just rationalizing why the client should be billed extra for a workaround to... your doing your damn job.

If you want ME to be responsible for that, then give ME control over the machine and you can go fill the forms at the unemployment office. There is no such thing as having control AND no duty. One or the other. Not both.
 
Last edited:
Briefly: if you insist on being the one installing crap on my system, yes, it is YOUR damn job to provide whatever version my program needs to do its job well and securely. You don't need to find idiotic excuses. You don't even need to know why. Just do your damn job instead of finding self-serving rationalizations as to why it's wrong to ask you to do what's in your job description. If the app X needs library Y in version Z, then do your job and provide that. Anything else is just rationalizing why the client should be billed extra for a workaround to... your doing your damn job.
Oh, I completely agree, and I am floundering in utter confusion regarding why you think I think otherwise and particularly why you are being so vehement about it. Please remember that I am talking about a stereotype, and not attacking developers in general.

If you want ME to be responsible for that, then give ME control over the machine and you can go fill the forms at the unemployment office. There is no such thing as having control AND no duty. One or the other. Not both.
I don't know where you got the impression that I want you to be responsible for that. I don't want you to be responsible for that. I don't want you to tell us how you'd fix it, and expect us to do exactly that. You tell us what the problem is, and we fix it by the most appropriate method. We work out what that is. That's our job.

It is your job to get on and do your job. When something goes wrong, it is our job to fix it so that you can do your job. Part of that is to determine the best way to fix it. There may be circumstances that factor in to that process that you are unaware of, because it's not your job to be aware of them. It is ours. Tell us to fix it and we'll fix it.

It's exactly like the people who have a problem with their computer, and instead of asking us to fix the problem, they ask us to reimage their PC. No. Tell us what your problem is, and we'll fix it. Reimaging the PC might be the way we do that, but probably not. We will determine how we'll fix the problem, not you, because it's our job, not yours.

Anyway, in this particular case their problem would have been fixed by the next version of the library, which is being made available to them next week. So really they were just being impatient.
 
Well, yes, but you also have to deal with a choleric client (product owner) who wants it fixed the day before yesterday, to understand why scheduling meetings to explain to you what the problem is and wait until next week may not be as fun and relaxed as you think. He got a meeting in his outlook last week for tomorrow to tell HIS boss that the application is secure against every exploit on nvd.nist.gov against those supposed Russian super-hackers when the attack in Ukraine started, he forgot to tell you until today, and he'll go full-tilt butthurt if he doesn't get a simple "yes" or "no" answer by 5 PM today. Like, even a more detailed explanation than "yes", "no", or "it'll be patched by tomorrow" will cause him to fly off the handle.

Not even exaggerating, that's literally the story of me dealing with the previous project's product owner, circa March this year. (And then having to tell HR why I sent a raging client a link to the "Don't Worry, Be Happy" clip on youtube. But that's another story for another time. Yeah, my sense of humour is so amazing, even HR wants to hear my jokes:p)
 
Not even exaggerating, that's literally the story of me dealing with the previous project's product owner, circa March this year. (And then having to tell HR why I sent a raging client a link to the "Don't Worry, Be Happy" clip on youtube. But that's another story for another time. Yeah, my sense of humour is so amazing, even HR wants to hear my jokes:p)
That is legit hilarious.
 
Status
Not open for further replies.

Back
Top Bottom