Like many people, if not most, I hate homework.
Especially I hate homework that has no purpose other than to inundate the student with busy work.
By the time I finished sophomore year I had had enough. I was burnt out. I needed a break.
I felt the impending wave of despair and desperation that would envelope me if I went into another semester of pointless homework and reading for classes whose ultimate purpose in my life was unclear to me.
The obvious escape route to this unending torrent of pointless busy work was to withdraw from school for a semester. But this was not a simple matter. There were two channels and only one of them was cost-effective: a co-op job or paid internship.
Before school let out in the spring I was reviewing all of the opportunities I could find and, eventually, I settled on one that met my needs and whose requirements I met. I interviewed for the position and I got it.
I commuted an hour each way, into the next state over, and I began my first "real-world" work experience in the realm of Management Information Systems.
I started on a Monday.
I began with a tour of the facility and introduction to the rest of the team.
Then, without much additional fanfare, I was tossed "to the wolves."
I worked on things that could be handled via phone for the remainder of Monday and through Tuesday.
Wednesday morning I arrived to work and, promptly at 8:00am, the phone rang. All of the other team members looked around and smiled. "Let's let the new guy take this" the sysadmin named Dave said.
Admiral Ackbar, with his most famous line from Return of the Jedi, popped into my mind as I replied "ok" and answered the phone.
The call was from Debbie in purchasing. Her computer would not turn on and, yes, it most certainly was plugged in. I promised her I would come down to check it out and got off the phone.
"Where's purchasing?" I asked.
"Go that way" Dave pointed "and stop at the end of the building. She's, literally, against the far wall."
I began my trek down the building, passing through accounting then the main lobby. I passed through manufacturing and shipping. I passed through service and another area of offices that I have either forgotten who they are or never knew and entered into the domain of purchasing.
Debbie was easy to find as she was standing, impatiently waiting for her solution. Her expression of sternness melted a bit when she realized that I was there to help her and that I was new.
I took a look around and verified that the computer would not, in fact, turn on.
My investigation ended a moment later when I discovered that the plug for her computer was only barely in the outlet, enough that a haphazard glimpse made it appear to be plugged in but loose enough that it was not making any significant contact with the terminals inside the outlet.
I reseated the plug into the outlet and tested the computer.
It sparked into life and Debbie was able to begin her workday.
I began my trek back through the various departments, pausing momentarily to note the terminal in manufacturing with the Budweiser Frogs screensaver that was burning frog images into the screen and the machine operator that was playing solitaire over the front of the CNC operation program.
I logged the case of Debbie and went about my day.
8:00AM on Wednesday, the following week, I answered the phone. It was Debbie. Her computer would not boot.
The process was identical in every respect. My journey, the nature of the problem, the solution, etc.
8:00AM on Wednesday, the following week, I answered the phone. It was Debbie. Her computer would not boot.
The process was identical in every respect. My journey, the nature of the problem, the solution, etc.
After the second repeat of this I inquired as to what was causing this and my colleagues provided me the answer. Apparently the housekeeping crew vacuums Purchasing on Tuesday nights and they fail, every week, to properly plug Debbie's computer back in. No amount of effort has managed to make them accomplish this simple task so, each Wednesday, Debbie calls MIS with the same problem.
8:00AM on Wednesday, the following week, I answered the phone. It was Debbie. Her computer would not boot.
This time, though, I deviated from the routine. I explained to Debbie what we had discovered and what we thought was causing the issue. I outlined that it was as simple as pushing on the plug to ensure it was fully in the wall. Debbie, accepted that this was possible, and watched me prove it.
8:00AM on Wednesday, the following week, I answered the phone. It was Debbie. Her computer would not boot.
I realized, then, that Debbie was never going to do the simple task of plugging her computer in to I began my trek.
The process was identical in every respect. My journey, the nature of the problem, the solution, etc.
I repeated this journey every Wednesday for the duration of my experience with the company and I had the great fortune to have my replacement and I overlap by a week at the end of my time.
On Wednesday, that week, at 8:00AM the phone rang. This time I got to be the one to say "How about we let the new guy handle this one?" as everyone else smiled.
He began his journey to Purchasing moments later.
Showing posts with label IT. Show all posts
Showing posts with label IT. Show all posts
Friday, September 5, 2014
Wednesday, September 3, 2014
The Rogue DHCP Server
Some things are best learned through experience.
The horror and frustration of them is a far more valuable lesson than the actual knowledge if read from a book. Losing data is one such lesson and there is really no way to make light of that event.
One of the horrors of losing data is that it can affect anyone.
Another such lesson, though, only affects network managers. Only plagues those who are responsible for the smooth operation of the network and the reliable access of resources for their users.
What makes this issue so insidious is that it is not obvious and it can plague the most well-prepared individuals; even more so those who are learning the eddies of troubles that managing a network can bring.
Imagine, if you will, a basic network built of the most basic networking equipment.
A network that is working perfectly and reliably. A network that maintains access to the core resources used by all of the users and which allows them to pass through to the outside world for general internet access. Imaging this should be no special task because, as you read these very words, you are using such a network or you used such a network to gain access to them. Such a network is seamless and the users make no notice of it just as they make no notice of the hallways or streets that they use until there is a problem.
The first indicator that I had that there was a problem was a routine helpdesk request. One of my users was unable to log on to the computer. Investigating the issue yielded a message that, at first glance, seemed a bit odd for my network but which was in the realm of possibility: an IP conflict.
The users could not access the network because the workstation had been shut off from the network because it had an identical address to another workstation. A simple reboot solved this problem and I verified that the workstation was getting its address from the network itself, as intended. I made a note of the address and began my investigation.
I checked my sheet of static addresses and found no matches.
I checked all of the devices that were supposed to have static addresses and they all had the addresses they were supposed to have.
I noted other machines around the building and none of them were having an issue.
I chalked the issue up to a random fluke and continued on.
Until another user informed me of the same problem the following morning.
And another.
And another.
And then several more.
I knew, then, that I had a serious problem on my hands but I had no idea what it could be.
I also knew that I had a limited window to find and solve the problem before my professional reputation was damaged and my "personal capital" in the organization would be completely and totally, and irrevocably, spent.
I examined the problem and found no inherent and obvious cause.
As I could not treat the disease I began preventative measures on the symptoms.
I reduced the range of assignable IP addresses and began statically assigning addresses to every affected user. I did this on the network side and hard-coded the addresses into the workstations themselves.
This, it turns out, was exactly the measure I needed to buy myself some more time.
With that time I turned to some online resources, which in the time of this tale were greatly diminished as compared to today, to get assistance on the root cause.
Reading and testing; more testing and more reading. I spent considerably time trying to understand where the problematic addresses were coming from but, regardless of my lack of comprehension they were still there. They still were being issued to anything that requested them. I was merely preventing things from asking for them.
The main clue that I received was that computers still pulling the addresses automatically were trying to use a different gateway than I had configured on my network. This little clue allowed me to deduce some more information, now that I had a few moments, as to the originating entity.
Most routers, if not all, have an interface that is visible to the network from the "inside." This interface is accessible by pointing a web browser at the address of the router. Unless otherwise specified this is the address that the router will hand out as the gateway.
So took the gateway address that I was seeing and entered it into the web browser of my affected machine.
BOOM. I was fed back a web interface to configure a router.
I now knew what I was looking for. I knew what the device was and how it was destroying my network.
What I didn't know was WHERE it was nor who had installed it in my building.
Somewhere, in my domain, was a Rogue Router.
And so began the great hunt.
After hours I went on safari, seeking the beast that was destroying the stability of my equipment and which was poised to consume my career prospects.
There was no better way, with the limited equipment I had to work with, to hunt this beast than to roam the vast halls; exploring room by room. I sought the beast.
For three nights I spent time migrating through the wilds of the network, physically examining the devices attached to the network in each of the many rooms I connected.
Until I beheld it.
In a room on the back wing I found a table.
On that table lay four additional workstations.
Four machines that were not supposed to be there.
Four machines that were not in my inventory.
Four computers that, combined with the other two in the room, could not POSSIBLY, connect into the four network ports that existed in that room.
Six machines simply could not use four network connections: the math just did not work.
I climbed under the table and followed the leads out of the wall. I moved around the edge of the table so that I could examine where the lines went as they moved from beneath to above the table.
I traced the line and I found my quarry.
Buried in a nest of cables it lay, lurking and waiting. Eating the productivity of all and consuming my reputation little by little.
There was the netgear router that was not supposed to be there.
It had one port that was not in use with one feeding into the wall and the remainder going to the computers. But the one that was not in use was the NOT a downstream port. It was the uplink.
Whomever had installed this router didn't know what they were doing and had uplinked my entire network into this router.
This was the source of the wrong addresses. This was the source of my pains.
This was the cause I consumed so much Tylenol in the previous week.
I unseated the cable that fed to the wall from the port it was nestled into and I seated it into the uplink port.
I made this change and I waited.
A week passed without any additional problems.
A week in which I could not find any trace of the issue.
A week in which I rebuilt my confidence and allowed others to believe I had contained, and eliminated, the problem.
A week that lasted an eternity while I waited, hoping that I had resolved the issue.
The following week I began the slow restoration of systems back to the proper configuration now that the danger had passed.
And then I went to the user who had built the mini lab in their room.
I went to her and I asked her why she had built it and where she had received the equipment.
I also, kindly, let her know the specifics of how it could disrupt the entire network in the future and that I needed her to ensure, if she hooked it up again in the future, that she matched how it was plugged in now.
My first IT crisis was averted.
One of the most important lessons was learned and I learned it the hard way.
The horror and frustration of them is a far more valuable lesson than the actual knowledge if read from a book. Losing data is one such lesson and there is really no way to make light of that event.
One of the horrors of losing data is that it can affect anyone.
Another such lesson, though, only affects network managers. Only plagues those who are responsible for the smooth operation of the network and the reliable access of resources for their users.
What makes this issue so insidious is that it is not obvious and it can plague the most well-prepared individuals; even more so those who are learning the eddies of troubles that managing a network can bring.
Imagine, if you will, a basic network built of the most basic networking equipment.
A network that is working perfectly and reliably. A network that maintains access to the core resources used by all of the users and which allows them to pass through to the outside world for general internet access. Imaging this should be no special task because, as you read these very words, you are using such a network or you used such a network to gain access to them. Such a network is seamless and the users make no notice of it just as they make no notice of the hallways or streets that they use until there is a problem.
The first indicator that I had that there was a problem was a routine helpdesk request. One of my users was unable to log on to the computer. Investigating the issue yielded a message that, at first glance, seemed a bit odd for my network but which was in the realm of possibility: an IP conflict.
The users could not access the network because the workstation had been shut off from the network because it had an identical address to another workstation. A simple reboot solved this problem and I verified that the workstation was getting its address from the network itself, as intended. I made a note of the address and began my investigation.
I checked my sheet of static addresses and found no matches.
I checked all of the devices that were supposed to have static addresses and they all had the addresses they were supposed to have.
I noted other machines around the building and none of them were having an issue.
I chalked the issue up to a random fluke and continued on.
Until another user informed me of the same problem the following morning.
And another.
And another.
And then several more.
I knew, then, that I had a serious problem on my hands but I had no idea what it could be.
I also knew that I had a limited window to find and solve the problem before my professional reputation was damaged and my "personal capital" in the organization would be completely and totally, and irrevocably, spent.
I examined the problem and found no inherent and obvious cause.
As I could not treat the disease I began preventative measures on the symptoms.
I reduced the range of assignable IP addresses and began statically assigning addresses to every affected user. I did this on the network side and hard-coded the addresses into the workstations themselves.
This, it turns out, was exactly the measure I needed to buy myself some more time.
With that time I turned to some online resources, which in the time of this tale were greatly diminished as compared to today, to get assistance on the root cause.
Reading and testing; more testing and more reading. I spent considerably time trying to understand where the problematic addresses were coming from but, regardless of my lack of comprehension they were still there. They still were being issued to anything that requested them. I was merely preventing things from asking for them.
The main clue that I received was that computers still pulling the addresses automatically were trying to use a different gateway than I had configured on my network. This little clue allowed me to deduce some more information, now that I had a few moments, as to the originating entity.
Most routers, if not all, have an interface that is visible to the network from the "inside." This interface is accessible by pointing a web browser at the address of the router. Unless otherwise specified this is the address that the router will hand out as the gateway.
So took the gateway address that I was seeing and entered it into the web browser of my affected machine.
BOOM. I was fed back a web interface to configure a router.
I now knew what I was looking for. I knew what the device was and how it was destroying my network.
What I didn't know was WHERE it was nor who had installed it in my building.
Somewhere, in my domain, was a Rogue Router.
And so began the great hunt.
After hours I went on safari, seeking the beast that was destroying the stability of my equipment and which was poised to consume my career prospects.
There was no better way, with the limited equipment I had to work with, to hunt this beast than to roam the vast halls; exploring room by room. I sought the beast.
For three nights I spent time migrating through the wilds of the network, physically examining the devices attached to the network in each of the many rooms I connected.
Until I beheld it.
In a room on the back wing I found a table.
On that table lay four additional workstations.
Four machines that were not supposed to be there.
Four machines that were not in my inventory.
Four computers that, combined with the other two in the room, could not POSSIBLY, connect into the four network ports that existed in that room.
Six machines simply could not use four network connections: the math just did not work.
I climbed under the table and followed the leads out of the wall. I moved around the edge of the table so that I could examine where the lines went as they moved from beneath to above the table.
I traced the line and I found my quarry.
Buried in a nest of cables it lay, lurking and waiting. Eating the productivity of all and consuming my reputation little by little.
There was the netgear router that was not supposed to be there.
It had one port that was not in use with one feeding into the wall and the remainder going to the computers. But the one that was not in use was the NOT a downstream port. It was the uplink.
Whomever had installed this router didn't know what they were doing and had uplinked my entire network into this router.
This was the source of the wrong addresses. This was the source of my pains.
This was the cause I consumed so much Tylenol in the previous week.
I unseated the cable that fed to the wall from the port it was nestled into and I seated it into the uplink port.
I made this change and I waited.
A week passed without any additional problems.
A week in which I could not find any trace of the issue.
A week in which I rebuilt my confidence and allowed others to believe I had contained, and eliminated, the problem.
A week that lasted an eternity while I waited, hoping that I had resolved the issue.
The following week I began the slow restoration of systems back to the proper configuration now that the danger had passed.
And then I went to the user who had built the mini lab in their room.
I went to her and I asked her why she had built it and where she had received the equipment.
I also, kindly, let her know the specifics of how it could disrupt the entire network in the future and that I needed her to ensure, if she hooked it up again in the future, that she matched how it was plugged in now.
My first IT crisis was averted.
One of the most important lessons was learned and I learned it the hard way.
Monday, September 1, 2014
Self-Powered
Sometimes, as an IT Professional, one encounters users that are happy to try to reassemble their computer on their own.
Given the reputation of scary IT people and those who are condescending to users, I have always found it important to allow users who wish to try the opportunity to try it out. Nothing reduces fear of the equipment faster and better than demystifying it.
Once upon a time, in my journey through a career as a technology manager, I encounter a user that was happy to reattach all of their equipment after a room move. I was asked, prior to their efforts, if I found it acceptable for them to undertake the effort and I assured them I was. I even stated that if they encountered any trouble to please let me know.
Later that day the user appeared in my door with an expression of concern adorning their face.
"I have a problem" they informed me, "it won't turn on."
I rose from my seat and escorted them back to their office area. Of course, the first question I asked was "is it plugged in" and the answer was an affirmative.
I began my troubleshooting, examining first, and last, if it was plugged in.
I found, to my acceptance, that all of the necessary cables appeared plugged in to the appropriate spaces. Network to network, USB plugs in USB ports (side note: a USB plug WILL fit into a network jack so "plug it in where it fits" doesn't work for all users). Monitor attached correctly. Everything seemed to be plugged in correctly; that is, until I looked at the wall socket.
There was nothing plugged into the electrical outlet in the wall. I knew, suddenly, that this MUST be the problem but where was the plug that needed to go there?
I traced all of the cables with my fingers until the culprit became clear. One of the plugs that is plugged into the surge protector was also the source cable for the surge protector. I gently unplugged this and slide it home, into the wall socket.
I rose, out from under the desk, and sparked on the system with the power button.
Everything fired up exactly as expected and my user was back in service.
Upon being asked what had been wrong I merely answered "one of your connections was arguing with us. It wanted to take a nap. I woke it up."
My user found this response amusing and accepted it.
I left their office and returned to my own to continue the tasks of monitoring servers and standing by for additional help as needed.
This is another true story tagged as "fiction" due to the story-telling nature of it.
The tale of the office move and the computer that wouldn't turn on because the power strip was plugged into itself
Given the reputation of scary IT people and those who are condescending to users, I have always found it important to allow users who wish to try the opportunity to try it out. Nothing reduces fear of the equipment faster and better than demystifying it.
Once upon a time, in my journey through a career as a technology manager, I encounter a user that was happy to reattach all of their equipment after a room move. I was asked, prior to their efforts, if I found it acceptable for them to undertake the effort and I assured them I was. I even stated that if they encountered any trouble to please let me know.
Later that day the user appeared in my door with an expression of concern adorning their face.
"I have a problem" they informed me, "it won't turn on."
I rose from my seat and escorted them back to their office area. Of course, the first question I asked was "is it plugged in" and the answer was an affirmative.
I began my troubleshooting, examining first, and last, if it was plugged in.
I found, to my acceptance, that all of the necessary cables appeared plugged in to the appropriate spaces. Network to network, USB plugs in USB ports (side note: a USB plug WILL fit into a network jack so "plug it in where it fits" doesn't work for all users). Monitor attached correctly. Everything seemed to be plugged in correctly; that is, until I looked at the wall socket.
There was nothing plugged into the electrical outlet in the wall. I knew, suddenly, that this MUST be the problem but where was the plug that needed to go there?
I traced all of the cables with my fingers until the culprit became clear. One of the plugs that is plugged into the surge protector was also the source cable for the surge protector. I gently unplugged this and slide it home, into the wall socket.
I rose, out from under the desk, and sparked on the system with the power button.
Everything fired up exactly as expected and my user was back in service.
Upon being asked what had been wrong I merely answered "one of your connections was arguing with us. It wanted to take a nap. I woke it up."
My user found this response amusing and accepted it.
I left their office and returned to my own to continue the tasks of monitoring servers and standing by for additional help as needed.
This is another true story tagged as "fiction" due to the story-telling nature of it.
The tale of the office move and the computer that wouldn't turn on because the power strip was plugged into itself
Monday, August 18, 2014
Is It Plugged In?
Users are a magical resource; an unending fount of challenges and puzzles.
An individual's level, aside from being a user, is completely irrelevant to whether or not they are a challenging user or not. It is also completely irrelevant as to whether they will successfully examine their own situation or not.
There are two initial questions that must always be the starting point of any technological troubleshooting:
1. Is it plugged in?
and
2. Is it turned on?
These are the logical first points of failure and they are asked because they are EASY to solve. These questions are asked not in a condescending manner and have even tripped up experienced technical individuals (the author acknowledges one incident of where each of these questions was the solution to his problem after considerable troubleshooting).
This is the story of one such situation.
It seems quite obvious, and was widely acknowledged, that no one in IT could assist a user unless they knew of the problem the user was experiencing. It was also quite widely accepted that IT did not have a magical clairvoyance that would allow them to know of the problems without them being reported. These axioms are the reasons that IT departments, and maintenance departments and, really, any service department, has a means to manage requests. The user who needs a service puts in a request and it is serviced as soon as it reaches the top of the queue. Many IT departments have a very strict means of submitting requests and others have a very lax manner of accepting requests; the important constancy is that they must get requests to be able to provide any service or support.
After a decent career as an IT monkey I made my way into a role as the entire IT department for a small school system. I held this job for two years before moving into a larger schools system where I became the department head of the IT department. Upon taking control of the department I went about the process of familiarizing myself with the helpdesk system that was in place and, through necessity, investigating the reason why no one would use it. After considerably examination of the administrative side I opted to examine it from the user side and my quandary was resolved. The previous director had made the system nearly impossible to operate from a user viewpoint. I corrected the issue and proceeded to campaign heavily for users to use the system while still accepting requests via email.
In a shameless effort to decrease efficiency and increase bureaucracy the Superintendent of this district required all department heads (including Principals) to attend a half-day meeting every other week. This meeting, which rotated around the schools, was designed to bring up items for discussion that were concerning to anyone in attendance. Most often the items placed on the agenda affected only the member who was discussing it and the Superintendent. With the exception of budget preparation these meeting were, primarily, a waste of time for me.
About a third of the way through the school year, long enough for me to have revamped the entire helpdesk system to be more user friendly and have had my campaign be heard nearly everywhere, I was attending one such meeting in one of the schools.
Moments after the meeting began we started around the room to address agenda items from individual users. That's when it happened.
The metaphorical bus was driven by an elementary school principal. It was driven hard and fast and it was driven true. It hit me with the force of managerial shame and stained my reputation in front of all of the principals and the superintendent. The bus took the form of a single question, asked in a sarcastic and snarky tone: "When are you going to fix my printer?"
"Did you submit a request for it?" I replied, attempting to hide my contempt for the manner of inquisition and working to retain an innocent and professional demeanor.
"Of course I did!" was the, still snarky, reponse.
"Oh, I see. Did you use the helpdesk system or just email one of us?" I asked, in an effort to narrow down my options.
"Both."
"OK. While I look for it, could you tell me what it is doing?"
"It's not printing" was the only answer I received.
"I can't seem to find a ticket in my email, in the helpdesk or even in the emails of either tech. Let me just take a moment to go ahead and make this ticket for you."
"Well, I know I submitted it."
Closing my laptop again, as the Superintendent did not like them present in the meetings, I asked the first of the two questions, "is your printer plugged in?"
The reply was explosive. Based on the response one would have assumed that I had criticized the principal's ability to do simple arithmetic or tie shoes. "Of course it's plugged in! I might not be a technical person but I know to check THAT." Hiding behind the words were additional messages that that could not have been clearer had they been spoken aloud. "How DARE you question my intelligence in front of our boss with that question? How could you possibly insult me like this? Who do you think you are?"
Chuckling a bit I replied "It's the first question we always ask, the first thing we check. The next thing is whether or not its turned on. You'd be surprised how many times one of those is the problem; even when we're the one experiencing it. I'll pop across the hall during the break and check on it for you."
The next hour passed slowly. The principal spent the time talking about issues in the school or glaring at me for the perceived insult I had laid upon them in front of our peers. Invisible daggers were flying through the air and, as needed, I dodged them skillfully.
The mid-morning break rolled into being and I popped up "Let me see what I can do about that printer." I was pleased to get out of the room for a variety of reasons.
The office was, literally, directly across the hallway. I walked into the inner office and found the laptop, resting happily on the stand that was used to hold it. I noted that the power cord was plugged into the laptop and so were two USB cables: one white, one black. I noticed the printer, sitting quietly in the corner of the desk with its power light lit up green. One quick look over the top of it showed me an important clue: a transparent USB cable.
I reached out and looped a finger under the cable and gently pulled. Up, up and up some more: there was no resistance to my efforts. Moments, and about three feet, passed when the far end of the cable appeared from behind the desk, dangling in the air before my eyes.
Turning my head I found that the black USB cable that was plugged into the computer ran to a palm pilot docking cradle and the white to the keyboard. Examining the keyboard yielded two USB ports, one of which had the mouse plugged into it.
I simply unplugged the palm pilot cradle from the laptop and plugged it into the remaining port on the keyboard; replacing it with the USB able that ran to the printer.
Immediately upon the cable being seated into the laptop the printer woke and responded. It came to life and began to print a document. I took the moment to examine the printing queue and found that 57 copies of the same document had been sent to the printer (because, obviously, if the print command didn't work one should just do it again, and again, and again). I closed the print queue and grabbed the one page that had finished printing to take with me.
Crossing the hall felt good. I had solved the problem and I had the chance to redeem myself in the eyes of my peers and my supervisor.
I strolled into the room, the last to rejoin the group, and handed the paper to the principal whose office I had just quitted.
"Is this the document you were trying to print?" I asked, politely and nicely.
"Yes" was the short reply, "thank you."
"No problem. Glad I could take care of it for you. The rest is printing now."
I sat, ready to rejoin the meeting without another word but the snarkiness from the other side couldn't be contained. "Well, what was wrong with it?" I was asked, in an effort to corner me in the room with everyone watching; an effort to back the bus back over me after the earlier inflicted professional wounds.
"Oh, it was easy. It wasn't plugged in, as soon as I plugged it in it started printing. If you'll all pardon me a moment I'll just go ahead and close the case I opened for this in our ticket system."
I opened the laptop. I opened the ticket file. I changed its status to closed and applied the status to my laptop, too.
The meeting resumed with me trying to avoid smiling and with another party fuming so greatly that one might mistake them for an active volcano that is ready to explode.
No one in that district questioned my inquiry about being plugged in again.
An individual's level, aside from being a user, is completely irrelevant to whether or not they are a challenging user or not. It is also completely irrelevant as to whether they will successfully examine their own situation or not.
There are two initial questions that must always be the starting point of any technological troubleshooting:
1. Is it plugged in?
and
2. Is it turned on?
These are the logical first points of failure and they are asked because they are EASY to solve. These questions are asked not in a condescending manner and have even tripped up experienced technical individuals (the author acknowledges one incident of where each of these questions was the solution to his problem after considerable troubleshooting).
This is the story of one such situation.
It seems quite obvious, and was widely acknowledged, that no one in IT could assist a user unless they knew of the problem the user was experiencing. It was also quite widely accepted that IT did not have a magical clairvoyance that would allow them to know of the problems without them being reported. These axioms are the reasons that IT departments, and maintenance departments and, really, any service department, has a means to manage requests. The user who needs a service puts in a request and it is serviced as soon as it reaches the top of the queue. Many IT departments have a very strict means of submitting requests and others have a very lax manner of accepting requests; the important constancy is that they must get requests to be able to provide any service or support.
After a decent career as an IT monkey I made my way into a role as the entire IT department for a small school system. I held this job for two years before moving into a larger schools system where I became the department head of the IT department. Upon taking control of the department I went about the process of familiarizing myself with the helpdesk system that was in place and, through necessity, investigating the reason why no one would use it. After considerably examination of the administrative side I opted to examine it from the user side and my quandary was resolved. The previous director had made the system nearly impossible to operate from a user viewpoint. I corrected the issue and proceeded to campaign heavily for users to use the system while still accepting requests via email.
In a shameless effort to decrease efficiency and increase bureaucracy the Superintendent of this district required all department heads (including Principals) to attend a half-day meeting every other week. This meeting, which rotated around the schools, was designed to bring up items for discussion that were concerning to anyone in attendance. Most often the items placed on the agenda affected only the member who was discussing it and the Superintendent. With the exception of budget preparation these meeting were, primarily, a waste of time for me.
About a third of the way through the school year, long enough for me to have revamped the entire helpdesk system to be more user friendly and have had my campaign be heard nearly everywhere, I was attending one such meeting in one of the schools.
Moments after the meeting began we started around the room to address agenda items from individual users. That's when it happened.
The metaphorical bus was driven by an elementary school principal. It was driven hard and fast and it was driven true. It hit me with the force of managerial shame and stained my reputation in front of all of the principals and the superintendent. The bus took the form of a single question, asked in a sarcastic and snarky tone: "When are you going to fix my printer?"
"Did you submit a request for it?" I replied, attempting to hide my contempt for the manner of inquisition and working to retain an innocent and professional demeanor.
"Of course I did!" was the, still snarky, reponse.
"Oh, I see. Did you use the helpdesk system or just email one of us?" I asked, in an effort to narrow down my options.
"Both."
"OK. While I look for it, could you tell me what it is doing?"
"It's not printing" was the only answer I received.
"I can't seem to find a ticket in my email, in the helpdesk or even in the emails of either tech. Let me just take a moment to go ahead and make this ticket for you."
"Well, I know I submitted it."
Closing my laptop again, as the Superintendent did not like them present in the meetings, I asked the first of the two questions, "is your printer plugged in?"
The reply was explosive. Based on the response one would have assumed that I had criticized the principal's ability to do simple arithmetic or tie shoes. "Of course it's plugged in! I might not be a technical person but I know to check THAT." Hiding behind the words were additional messages that that could not have been clearer had they been spoken aloud. "How DARE you question my intelligence in front of our boss with that question? How could you possibly insult me like this? Who do you think you are?"
Chuckling a bit I replied "It's the first question we always ask, the first thing we check. The next thing is whether or not its turned on. You'd be surprised how many times one of those is the problem; even when we're the one experiencing it. I'll pop across the hall during the break and check on it for you."
The next hour passed slowly. The principal spent the time talking about issues in the school or glaring at me for the perceived insult I had laid upon them in front of our peers. Invisible daggers were flying through the air and, as needed, I dodged them skillfully.
The mid-morning break rolled into being and I popped up "Let me see what I can do about that printer." I was pleased to get out of the room for a variety of reasons.
The office was, literally, directly across the hallway. I walked into the inner office and found the laptop, resting happily on the stand that was used to hold it. I noted that the power cord was plugged into the laptop and so were two USB cables: one white, one black. I noticed the printer, sitting quietly in the corner of the desk with its power light lit up green. One quick look over the top of it showed me an important clue: a transparent USB cable.
I reached out and looped a finger under the cable and gently pulled. Up, up and up some more: there was no resistance to my efforts. Moments, and about three feet, passed when the far end of the cable appeared from behind the desk, dangling in the air before my eyes.
Turning my head I found that the black USB cable that was plugged into the computer ran to a palm pilot docking cradle and the white to the keyboard. Examining the keyboard yielded two USB ports, one of which had the mouse plugged into it.
I simply unplugged the palm pilot cradle from the laptop and plugged it into the remaining port on the keyboard; replacing it with the USB able that ran to the printer.
Immediately upon the cable being seated into the laptop the printer woke and responded. It came to life and began to print a document. I took the moment to examine the printing queue and found that 57 copies of the same document had been sent to the printer (because, obviously, if the print command didn't work one should just do it again, and again, and again). I closed the print queue and grabbed the one page that had finished printing to take with me.
Crossing the hall felt good. I had solved the problem and I had the chance to redeem myself in the eyes of my peers and my supervisor.
I strolled into the room, the last to rejoin the group, and handed the paper to the principal whose office I had just quitted.
"Is this the document you were trying to print?" I asked, politely and nicely.
"Yes" was the short reply, "thank you."
"No problem. Glad I could take care of it for you. The rest is printing now."
I sat, ready to rejoin the meeting without another word but the snarkiness from the other side couldn't be contained. "Well, what was wrong with it?" I was asked, in an effort to corner me in the room with everyone watching; an effort to back the bus back over me after the earlier inflicted professional wounds.
"Oh, it was easy. It wasn't plugged in, as soon as I plugged it in it started printing. If you'll all pardon me a moment I'll just go ahead and close the case I opened for this in our ticket system."
I opened the laptop. I opened the ticket file. I changed its status to closed and applied the status to my laptop, too.
The meeting resumed with me trying to avoid smiling and with another party fuming so greatly that one might mistake them for an active volcano that is ready to explode.
No one in that district questioned my inquiry about being plugged in again.
Friday, January 21, 2011
An Interesting Comedy of Errors
If one of the days this week had been a movie then the volume of freakish errors might have been funny... to anyone not in IT.
To me, who is not only in IT but also the person whom the errors occurred to, it was the farthest thing from funny.
For the sake of brevity I will minimize everything. I also hope my misfortune of the day in question brings some perspective on other things that may seem bad to both myself and others.
Also - I hope it amuses those who can find humor in it. I'm sure someday I will be able to find amusement in it.
The story begins with the knowledge that there is one, singular individual in my place of employment whom I cannot afford to have anything go wrong with their computer. My first interactions with this individual were hostile (from them) and they firmly believe that we're doing just about everything wrong in the technology department here. They don't do this job, but they think we're doing things wrong anyway.
A day earlier this week this user approached me because something was not working on their computer. As it was the end of the day I told them that I would happily fix the issue first thing in the morning the next time I was in their building.
The day of fixing arrived and I went to collect the computer but the user was in a meeting. I had to choose to interrupt the meeting or try to catch the user when the meeting was over. I chose to wait as it seemed the less potentially dangerous mistake to make.
I caught up with the user shortly after their meeting and collected the computer to work on it in the tech office.
I tried every trick I knew and I was unable to correct the problem at hand. This meant a re-image was necessary.
I backed up the user's data using a THOROUGHLY tested and valid backup procedure. Then, before kicking off the imaging process I tested to make sure that the backup had worked correctly. It had. All the data was there and it was valid.
I kicked off the imaging process. It ran, without incident, through to completion.
It is important to note that I have developed a new little application that makes the automated backup and restore process easier to use. To do so it, basically, adds a GUI layer to execute the known-good scripts. Part of the imaging process places this application on the laptop's admin's desktop. I deliberately chose NOT to use this application as I have not tested it in a production environment and I couldn't afford to have ANYTHING go wrong with this process.
I ran the "tried and true" command line script that works perfectly EVERY TIME. I've run it on my own data. I've run it on MANY other users' data. Once I perfected it and put it into production I have had no errors from the script - only errors when the hard disk (either origin or destination) were failing.
The script started normally. It did the things it normally does. Then, halfway through the process, it errors out and the drive unmounts (not the other two partitions of the physical disk, just the one in question) and re-mounted. It re-mounted EMPTY.
That's right: the data was GONE. Some settings (not enough to be useful) and half a file (wouldn't open in the appropriate file) managed to be restored before it crashed. Nothing useful remained.
So I altered my day to finish setting up the workstation so the user could, at least, work on new stuff and set about the process of data recovery.
The first tool I used scanned for a hair over four hours.
In the midst of the recovery process (post four hour scan, into active analysis of the recovered files) the wireless network of that particular building completely died. Totally and completely died. I was posting a tweet and that process stalled. I was loading the the Google search pane and the Google logo of the day actually halted mid-load because of the network dying. I had to stop what I was doing and determine where the problem was and try to rectify it (I did with a simultaneous reboot of the entire wireless infrastructure).
I was then able to return to the task of file recovery. I recovered some files, but I doubt any were the files the user needed. I went to put them on the USB disk, as I promised the user I would and the USB disk I had handy for this purpose wouldn't mount. It wouldn't respond. It is dead. I ended up emailing the files instead.
The second tool I tried to use failed to work at all.
Today I am running the second tool from a different machine in an attempt to reclaim the lost partition. If I can reclaim the lost partition I can not only recover all (most?) of the files lost but also things like saved bookmarks, etc.
It is running now. It has found multiple old partitions. I will have to guess at which one I need to restore. Hopefully I choose wisely.
RESOLUTION - due to oversight this was added nearly four years later - I was able to restore the data.
To me, who is not only in IT but also the person whom the errors occurred to, it was the farthest thing from funny.
For the sake of brevity I will minimize everything. I also hope my misfortune of the day in question brings some perspective on other things that may seem bad to both myself and others.
Also - I hope it amuses those who can find humor in it. I'm sure someday I will be able to find amusement in it.
The story begins with the knowledge that there is one, singular individual in my place of employment whom I cannot afford to have anything go wrong with their computer. My first interactions with this individual were hostile (from them) and they firmly believe that we're doing just about everything wrong in the technology department here. They don't do this job, but they think we're doing things wrong anyway.
A day earlier this week this user approached me because something was not working on their computer. As it was the end of the day I told them that I would happily fix the issue first thing in the morning the next time I was in their building.
The day of fixing arrived and I went to collect the computer but the user was in a meeting. I had to choose to interrupt the meeting or try to catch the user when the meeting was over. I chose to wait as it seemed the less potentially dangerous mistake to make.
I caught up with the user shortly after their meeting and collected the computer to work on it in the tech office.
I tried every trick I knew and I was unable to correct the problem at hand. This meant a re-image was necessary.
I backed up the user's data using a THOROUGHLY tested and valid backup procedure. Then, before kicking off the imaging process I tested to make sure that the backup had worked correctly. It had. All the data was there and it was valid.
I kicked off the imaging process. It ran, without incident, through to completion.
It is important to note that I have developed a new little application that makes the automated backup and restore process easier to use. To do so it, basically, adds a GUI layer to execute the known-good scripts. Part of the imaging process places this application on the laptop's admin's desktop. I deliberately chose NOT to use this application as I have not tested it in a production environment and I couldn't afford to have ANYTHING go wrong with this process.
I ran the "tried and true" command line script that works perfectly EVERY TIME. I've run it on my own data. I've run it on MANY other users' data. Once I perfected it and put it into production I have had no errors from the script - only errors when the hard disk (either origin or destination) were failing.
The script started normally. It did the things it normally does. Then, halfway through the process, it errors out and the drive unmounts (not the other two partitions of the physical disk, just the one in question) and re-mounted. It re-mounted EMPTY.
That's right: the data was GONE. Some settings (not enough to be useful) and half a file (wouldn't open in the appropriate file) managed to be restored before it crashed. Nothing useful remained.
So I altered my day to finish setting up the workstation so the user could, at least, work on new stuff and set about the process of data recovery.
The first tool I used scanned for a hair over four hours.
In the midst of the recovery process (post four hour scan, into active analysis of the recovered files) the wireless network of that particular building completely died. Totally and completely died. I was posting a tweet and that process stalled. I was loading the the Google search pane and the Google logo of the day actually halted mid-load because of the network dying. I had to stop what I was doing and determine where the problem was and try to rectify it (I did with a simultaneous reboot of the entire wireless infrastructure).
I was then able to return to the task of file recovery. I recovered some files, but I doubt any were the files the user needed. I went to put them on the USB disk, as I promised the user I would and the USB disk I had handy for this purpose wouldn't mount. It wouldn't respond. It is dead. I ended up emailing the files instead.
The second tool I tried to use failed to work at all.
Today I am running the second tool from a different machine in an attempt to reclaim the lost partition. If I can reclaim the lost partition I can not only recover all (most?) of the files lost but also things like saved bookmarks, etc.
It is running now. It has found multiple old partitions. I will have to guess at which one I need to restore. Hopefully I choose wisely.
RESOLUTION - due to oversight this was added nearly four years later - I was able to restore the data.
Thursday, September 9, 2010
Two Humorous End-User Stories
On the heels of my last post I wanted to share these two stories about end users doing foolish things.
The first is from one of my earliest jobs in technical support. I worked for a manufacturing company that was contained in a single LONG building. IT was about a quarter of the way into one end. My first Wednesday on the job the IT office phone rang at 8:03AM.
No one moved to answer it.
I looked around the room and noticed everyone else looking around the room. After the third ring one of the other guys said "That's Debbie" and stated that I should take it as my first call.
I took the call.
Debbie's computer would not turn on. I went through the normal trouble-shooting steps starting with "is it plugged in?" and moving from there.
Nothing worked.
I told Debbie I would be right down.
It turns out Debbie's workspace is the farthest possible workspace from the IT office. Debbie, literally, faces the exterior wall of the building on the far end of the building from the IT office. I had to walk through every department except engineering (including the manufacturing floor) to get there.
After my nice 10 minute walk I arrived at Debbie's cubicle and looked around.
I immediately looked under her desk and found that her computer's power plug was hanging loosely from the outlet. I pushed it into the wall and *poof* the computer was able to boot.
I walked back to the IT office.
The next Wednesday, at 8:03 AM, the IT office phone rang. It was Debbie. Her computer wouldn't boot.
For the remainder of my time with that company my Wednesday morning routine was to walk to Debbie's department and, literally, plug her computer in for her.
The next story is several years later.
I was responsible for the technology department in the organization I was working for. Part of that responsibility was to attend meetings with all of the other department heads for one morning every other week. We ALL hated these meetings. They cut into our productivity and returned us nothing for our time. Our collective boss LOVED these meetings. But I digress.
At one of these meetings the performance of my department as it related to one of the buildings arose. The problem we had in that building was that no one would enter a help request when something broke. They, instead, would complain that it was broken to each other for two weeks then complain for another week to the person in charge of the building who would, eventually, email one of the tech support staff to complain that it had not been fixed (note: still NOT submitting a proper help request). We would then create the proper help request and go fix the problem that day.
The discussion was entirely focused around our lack of responsiveness in that building. I stated that we serviced the items as soon as we received word that our services were needed and reiterated that we are unable to fix broken equipment until we know it is broken.
The person in charge of the building stated that my department was ALWAYS notified as soon as something was broken and that we just ALWAYS took three weeks to fix it.
Then the boss asked for a recent example of something that did not work.
The person in charge of the building answered, without hesitation, "my printer."
I replied with "did you submit a help request on it?" and received an affirmative.
I looked in the help request and pointed out that no such request had been received.
I also did a search on ALL of the email from that user and verified that I had not received a help request via email (not the proper method of submitting a request).
I also emailed every technician in my department and asked them if any of them had received word. My reply for all of them was nearly immediate: "no."
I pointed out that we hadn't fixed the printer because no one knew it was broken until just then. I also promised to go take a look at it during our mid-morning break but I first asked "did you check to make sure that the printer is plugged in?"
The user was furious and flabbergasted that I would DARE to ask such a question. OF COURSE they knew to check and make sure it was plugged in. That is the first step of troubleshooting technology. EVERYONE knows to check to make sure it is plugged in. Surely I didn't think that they were stupid?
I replied with the excessive response with a "Sorry. I did not mean to offend you. It's the first thing to check and even my staff have found that they were caught in things not being plugged in."
The break came.
I went and looked at the situation.
I noticed that the printer was on and it had several status lights lit up.
I also noticed that the USB cord coming out of the printer had transparent insulation.
I looked at the user's laptop. It had two USB cords plugged into it. Both of them were black. One went to the PalmPilot sync cradle and the other to an external keyboard.
I reached back and pulled on the printer's USB cable. It came out from behind the desk without resistance to show that it was plugged into nothing.
I then unplugged the user's PalmPilot sync cradle from the laptop and plugged it into the spare USB port in the side of the external keyboard. I then plugged in the printer.
As soon as the printer's USB cable was plugged in the printer sprang to life and starting spewing paper.
I opened the print queue for the printer and found more than 10 copies of the same document in the queue as well as multiple copies of other documents.
I took the first copy of the first document with me when I went back to the meeting as proof that the printer was now working.
My statement was, simply, "You're all set now. It's printing out the things you sent to it."
The user, of course, was not satisfied with that and HAD to ask "well, what was wrong with it."
I simply answered "It wasn't plugged in to your laptop."
EDIT: both of these stories were expanded upon and made into singular instances later on and appear in later posts
The first is from one of my earliest jobs in technical support. I worked for a manufacturing company that was contained in a single LONG building. IT was about a quarter of the way into one end. My first Wednesday on the job the IT office phone rang at 8:03AM.
No one moved to answer it.
I looked around the room and noticed everyone else looking around the room. After the third ring one of the other guys said "That's Debbie" and stated that I should take it as my first call.
I took the call.
Debbie's computer would not turn on. I went through the normal trouble-shooting steps starting with "is it plugged in?" and moving from there.
Nothing worked.
I told Debbie I would be right down.
It turns out Debbie's workspace is the farthest possible workspace from the IT office. Debbie, literally, faces the exterior wall of the building on the far end of the building from the IT office. I had to walk through every department except engineering (including the manufacturing floor) to get there.
After my nice 10 minute walk I arrived at Debbie's cubicle and looked around.
I immediately looked under her desk and found that her computer's power plug was hanging loosely from the outlet. I pushed it into the wall and *poof* the computer was able to boot.
I walked back to the IT office.
The next Wednesday, at 8:03 AM, the IT office phone rang. It was Debbie. Her computer wouldn't boot.
For the remainder of my time with that company my Wednesday morning routine was to walk to Debbie's department and, literally, plug her computer in for her.
The next story is several years later.
I was responsible for the technology department in the organization I was working for. Part of that responsibility was to attend meetings with all of the other department heads for one morning every other week. We ALL hated these meetings. They cut into our productivity and returned us nothing for our time. Our collective boss LOVED these meetings. But I digress.
At one of these meetings the performance of my department as it related to one of the buildings arose. The problem we had in that building was that no one would enter a help request when something broke. They, instead, would complain that it was broken to each other for two weeks then complain for another week to the person in charge of the building who would, eventually, email one of the tech support staff to complain that it had not been fixed (note: still NOT submitting a proper help request). We would then create the proper help request and go fix the problem that day.
The discussion was entirely focused around our lack of responsiveness in that building. I stated that we serviced the items as soon as we received word that our services were needed and reiterated that we are unable to fix broken equipment until we know it is broken.
The person in charge of the building stated that my department was ALWAYS notified as soon as something was broken and that we just ALWAYS took three weeks to fix it.
Then the boss asked for a recent example of something that did not work.
The person in charge of the building answered, without hesitation, "my printer."
I replied with "did you submit a help request on it?" and received an affirmative.
I looked in the help request and pointed out that no such request had been received.
I also did a search on ALL of the email from that user and verified that I had not received a help request via email (not the proper method of submitting a request).
I also emailed every technician in my department and asked them if any of them had received word. My reply for all of them was nearly immediate: "no."
I pointed out that we hadn't fixed the printer because no one knew it was broken until just then. I also promised to go take a look at it during our mid-morning break but I first asked "did you check to make sure that the printer is plugged in?"
The user was furious and flabbergasted that I would DARE to ask such a question. OF COURSE they knew to check and make sure it was plugged in. That is the first step of troubleshooting technology. EVERYONE knows to check to make sure it is plugged in. Surely I didn't think that they were stupid?
I replied with the excessive response with a "Sorry. I did not mean to offend you. It's the first thing to check and even my staff have found that they were caught in things not being plugged in."
The break came.
I went and looked at the situation.
I noticed that the printer was on and it had several status lights lit up.
I also noticed that the USB cord coming out of the printer had transparent insulation.
I looked at the user's laptop. It had two USB cords plugged into it. Both of them were black. One went to the PalmPilot sync cradle and the other to an external keyboard.
I reached back and pulled on the printer's USB cable. It came out from behind the desk without resistance to show that it was plugged into nothing.
I then unplugged the user's PalmPilot sync cradle from the laptop and plugged it into the spare USB port in the side of the external keyboard. I then plugged in the printer.
As soon as the printer's USB cable was plugged in the printer sprang to life and starting spewing paper.
I opened the print queue for the printer and found more than 10 copies of the same document in the queue as well as multiple copies of other documents.
I took the first copy of the first document with me when I went back to the meeting as proof that the printer was now working.
My statement was, simply, "You're all set now. It's printing out the things you sent to it."
The user, of course, was not satisfied with that and HAD to ask "well, what was wrong with it."
I simply answered "It wasn't plugged in to your laptop."
EDIT: both of these stories were expanded upon and made into singular instances later on and appear in later posts
Commentary on Users
I work in I.T.
For those that do not know, I.T. is an abbreviation for "Information Technology."
At its simplest that is a fancy way of saying "Tech Support" even though, for many (myself included) it is MUCH more than simple technical support for the end user.
That said, most I.T. professionals have to work with end users from time to time. Some on a daily basis, some rarely. But end users are the inevitable reality that provides I.T. professionals with work.
We are at an interesting time when many of the end users did not develop in a world with computers as an everyday fact of life. This is an interesting sociological development but, as it relates to I.T. it is something VERY important to remember. What it means is that some users simply do not grok computers. At all. Even a little. Everything about the idea of a computer is foreign and scary to them.
Other users understand the concepts of computers but lack the knowledge to use them properly.
I work with people in each of these categories every day. I am happy to work with them and I do my best to not express frustration with them when a task I think of as simple is a barrier to them.
My patience, however, has limits.
When a user gives bogus excuses for not being able to use technology I will stop them. The most common one of these is "I'm too old to use a computer." I am particularly offended by this because the "I'm too old" complaint is charged on multiple levels.
Mostly, though, my limits are exceeded when a user is blatantly hostile toward myself, or any of the I.T. staff here. Being hostile to the people who are there to help you is NEVER the right way to get the help and support you need. This is a lesson that is true in EVERY aspect of life and one everyone should keep in mind more often.
I know I try to be cordial and nice to whomever I am speaking with when I am seeking support and assistance. I don't always succeed, but I do try.
None of these categories represent the majority of my users. I think that this is something that many (perhaps most) I.T. professionals forget. Most of your users never ask for your help because they accomplish what they need to accomplish on their own. Those that ask for help are the ones that need it the most (either through malfunction of equipment or user) and we all need to remember that the users we never hear from are the ones we like to have.
So I am going to end this post with a thank you to the end users who never need my help as well as a bigger thank you to those who are constantly supportive of the help that I.T. professionals provide and the hard work we do.
For those that do not know, I.T. is an abbreviation for "Information Technology."
At its simplest that is a fancy way of saying "Tech Support" even though, for many (myself included) it is MUCH more than simple technical support for the end user.
That said, most I.T. professionals have to work with end users from time to time. Some on a daily basis, some rarely. But end users are the inevitable reality that provides I.T. professionals with work.
We are at an interesting time when many of the end users did not develop in a world with computers as an everyday fact of life. This is an interesting sociological development but, as it relates to I.T. it is something VERY important to remember. What it means is that some users simply do not grok computers. At all. Even a little. Everything about the idea of a computer is foreign and scary to them.
Other users understand the concepts of computers but lack the knowledge to use them properly.
I work with people in each of these categories every day. I am happy to work with them and I do my best to not express frustration with them when a task I think of as simple is a barrier to them.
My patience, however, has limits.
When a user gives bogus excuses for not being able to use technology I will stop them. The most common one of these is "I'm too old to use a computer." I am particularly offended by this because the "I'm too old" complaint is charged on multiple levels.
- The first is that many old people who point out their own age are looking for some sort of respect or discount or special treatment because of their age alone. I don't buy into that. You EARN respect from me. Everyone starts out the same and those who earn more respect get it and those who earn my disdain get that, too. This, of course, is a pet peeve of mine and a side-track from the core content of this post.
- The second reason I dislike the "I'm too old" comment is that it is self-prejudicial against the speaker. They're limiting their own options based on their perception of what old people should and should not be able to do.
- The third thing that bothers me by this is that it is blatantly not true. No one is too old to learn and no one is too old to use a computer. I have met people in their 90s using email and the internet on a daily basis. Unless you are older than they are you have no place telling me you're "too old" to use one.
- Lastly, I have a problem with it because it is a lame excuse to try and hide intellectual laziness. When you use the "I'm too old" excuse you're really saying to me "I'm too mentally lazy to even try."
Mostly, though, my limits are exceeded when a user is blatantly hostile toward myself, or any of the I.T. staff here. Being hostile to the people who are there to help you is NEVER the right way to get the help and support you need. This is a lesson that is true in EVERY aspect of life and one everyone should keep in mind more often.
I know I try to be cordial and nice to whomever I am speaking with when I am seeking support and assistance. I don't always succeed, but I do try.
None of these categories represent the majority of my users. I think that this is something that many (perhaps most) I.T. professionals forget. Most of your users never ask for your help because they accomplish what they need to accomplish on their own. Those that ask for help are the ones that need it the most (either through malfunction of equipment or user) and we all need to remember that the users we never hear from are the ones we like to have.
So I am going to end this post with a thank you to the end users who never need my help as well as a bigger thank you to those who are constantly supportive of the help that I.T. professionals provide and the hard work we do.
Subscribe to:
Posts (Atom)