Show me where I said that sysadmins were the only one this happens to.
Please don't confuse system administration with staffing a helpdesk.
Just because you don't like dealing with unreasonable jerks doesn't make you unfit for a job where you occasionally have to deal with unreasonable jerks.
And for all of you following this thread: For every one of the incidents I mentioned originally, there were hundreds where users' problems were solved without incident, where infrastructure problems were solved without the users even knowing it, and where everybody involved said "please" and "thank you". For every 4:30pm Friday (non)emergency, there were hundreds of cases where people asked well in advance for things they knew it would take a lot of effort to provide. For every person who filed a ticket saying nothing but "I have a problem--call", there were hundreds that spelled out their requests in enough detail that the only thing I had to say back to them is, "It's done."
Especially gratifying were the times I announced a new capability, and had people ask how I knew they were going to be needing it.
Don't make this about me, personally. If you think from what you've read here that I'm a lousy sysadmin, or horrible to work with, don't hire me. But it's not just me. Every one of us has to deal with sysadmins, administrative assistants, procurement departments, IT desktop support people, our own bosses, and all the other people out there whom we ask for things in order to get our jobs done.
At the particular job where all this happened (2003-2010), I was on a defense project with about 750 engineers across seven development sites. At ours, I supported about 130 people. At every other site, regardless of size, what I did was done by at least three full-time staff. I actually got pretty good at all the things you claim I can't do, from prioritization to automation to virtualization. Pretty much anything that happened more than twice became a documented procedure, as did many things that never happened at all but I still planned for. My lab got audited internally or by the government three times a year without a single finding, and some of those procedures got recommended as company-wide standards. There was never an instance of data loss. No deliverable was ever late due to lab issues. The infrastructure I built out was intended to be adequate for three years but lasted through the end of the project.
My value to the business? That was measured quantitatively by project management: We had two extra full-time engineers working on revenue-generating deliverables because of what I was doing by myself instead of with two other sysadmins, one more because of what I saved in hardware and software costs, and 2.5 more across the project because of process improvements I developed that were implemented project-wide.
Was I the best sysadmin ever? Of course not. I made lots of mistakes, and when I did, I owned up to them. When I behaved inappropriately (and don't tell me you never have) I apologized publicly to the people involved. And, unlike your posts, I never had to resort to swearing, mocking or name calling. Or is that somehing you do only behind the safety of your computer and your anonymity?
When did I ever say I didn't know how to handle those situations? I was just pointing out some of the more, um, challenging aspects of the job, for people who think systadmins are all Dennis Nedrys.
I'd sure like to know who all these ACs are who seem to know my job and the people I work with so much better than I do.
I'd aso like to know where in the multiverse there's a sysadmin who has the time and resources to automate every possible sequence of things a user might need to do, including users who are running experiments, doing one-off concept studies, having their requirements changed at the last minute, operating under crushing deadline pressure, and the like. Everything my users do, I've done. I've been every one of them at some point in my career. The kinds of assholery I describe are things I don't do to sysadmins, coworkers, even PHBs.
In any case, you're making my point: Follow me around for a day, and see if it's all really as simple as you're making it out to be.
If there weren't good parts of the job, we wouldn't do it. And the majority of users aren't lusers. There are some who we'd lay down in traffic for, because they understand our jobs are hard and thank us for what we do for them, not just by saying thank you but by making their requests clearly, giving us reasonable notive if the work is non-trivial, giving us reasonable time to do the work, and only calling something an emergency when it really is.
A lot of he time we just happen to be the one they blow off steam to when something out of their control makes their already bad day worse. I could have handled the 15-minute screamer several different ways. I could have stopped him after 15 seconds and told him how to file a ticket, except that he already had, both with me, and with the networking people. I could have told him to lower his voice or he'd be picking up his teeth with broken fingers. I could have turned my back on him mid-rant. What I did do was realize that this was nothing personal, let him scream himself out, then went back to waiting with everybody else for the network people to get the network running again.
Oh and to add to your Sysadmin 101 bullet points:
Make them want to file tickets by responding quickly and then using the ticketing system to communicate your progress in a timely fashion. Make sure the ticketing system is DEAD EASY to use--with ours, users never had to do anything more than send mail to help@oursite.ourcompany.com. Unless your job requires that you take requests over the phone or in person, don't.
Always remember what my wife, also a sysadmin, says: "Our job is to make the users productive, not to make them happy." Make them happy as much as you can (which is most of the time), but not at the expense of making them, or others, less productive.
No, sysadmins do NOT train new employees on company policy, HR does. No, sysadmins do NOT train new emplyees on basic computer science, college does. No, sysadmins do NOT train employess on the internals of the products they're working on, other developers do. No, sysadmins do NOT train new employees on how to boot Windows, edit a Word document, fire up a web browser, use a mouse, etc., their kids do.
Yes, there are things that sysadmins provide new employees: Things like which servers do which things, how to get access to the various systems necessary for their jobs, the names and locations of printers and network shares (and thir Unix/Linux equivalents), where to find things out that we don't (and often can't) tell them, how to file trouble tickets. But we are not supposed to be the first person the new guy comes to when they have questions about everything from how to set up their 401(k) deductions to where the best restaurants are.
I was thinking of a particular person at my last job. He'd work 48-72 hours, go home, sleep, then come back in and do it again. This was not a death-march project, and we had only about six weeks of real crunch time a year. Every now and then his management would try to get him to work saner hours; he'd take weekends off for a month or so, then get back to the old ways. He was brilliant, personally a pretty nice guy, shared his knowledge instead of hoarding it, and was a real asset to the project. We were just afraid he'd eventually burn out (or flame out), and we felt bad for his wife and kids.
I have a simple solution: Follow me around for a day (and a night).
Watch what happens when two people, either of whom could fire both of us, issue demands that are diametrically opposed and mutually exclusive.
Watch when the new guy gets ignored by his team members and forgets that Google exists so he comes to us expecting days of basic training on how to do his job.
Watch when the workaholic engineer expects us to be there around the clock for everything from new machines to coffee runs as he compulsively works his 72-hour shifts.
Watch when we spend six hours fixing a machine somebody botched horribly because we told them to push button A then button B then button C, but they pushed button B then button A then button C. For the third time.
Watch when Mr. Hot Temper screams at us for 15 minutes because the network is down, even though not only are we not permitted to do anything with the network, we're not even allowed into the wiring closet.
Watch how we're never thanked for anything, but we're informed on a regular basis as to what people think our mothers did for a living.
I could go on, but rest assured, you'll want your own job back.
OK, here's the slightest failing I've felt numerous times: Old laptop whose graphics under WinXP were just fine, if a little slow. Install Linux with your favorite desktop (LXDE works best for me on that machine). Machine is under moderate load. Click and drag a window to move it. When you release the mouse button, the window is still following the cursor, because the mouse-button-up event was not handled properly.
JWZ complained abut this sort of thing (events not being presented to the handler in proper order) when he was working on the Unix/X version of Mozilla. ISTR him saying that it was a problem wih the protocol itself, which would explain why the problem persists almost 20 years alter.
The same thing happened with HP/UX 9. HP tried all sorts of things, including free consulting to get customers to upgrade to 10.x, but the don't-fix-what-isn't-broken crowd kept driving their dump trucks to Cupertino. They finally ended it by pointing out that there was no way to make it Y2K compliant without breaking backwards binary compatibility.
I just took a 21" CRT to the recycling place. In 1995, it cost about $2200 new. In 2001, my employer gave it to me as scrap when our building was closed and they decided that a lot of that stuff was cheaper to give away than to move to some warehouse across the country. (Plus it was a tiny bit of good will that the local management could show the laid-off employees when the Big Guys were being callous pricks kicking us to the curb while we were still going to 9/11 funerals.)
ObTopic: $400 is an expensive monitor these days, but it wasn't that long ago that $400 wouldn't buy you a useable SVGA monitor.
The problem I have with Crees is th form factor. We have recessed lighting in our kitchen, mostly R30, and the fixtures are 40 years old, certainly superseded by newer standards. Regular R-30 bulbs fit perfectly. The Cree equivalents take some work to fit right, especially the ones with the built-in bezels.
That said, I love the light they produce. It's a bit brighter, and only slightly whiter than the light the 65W incandescents put out, at a fifth the power consumption.
I have one question for the pick-your-color manufacturers: Have you ever consulted an interior designer? The colors of paint, fabric, etc. in a room are all picked with specific lighting in mind, both natural and from lamps. Start futzing with it, and things will start looking crappy. Ever wonder why a hotel room looks fine under CFLs but the same CFLs in your bedroom make everything an ashy grey? It's because the colors in the hotel room were picked specifically because they complement the color spectrum put out by the CFLs.
I'm looking forward to the day not far off when I can have all LED lighting in the house, but I have no desire to make radical color changes (except for special applications people have mentioned ike aids for the deaf).
IBM support still sucks. You spend more time proving to them that you're entitled to support than you spend getting support. Customer number? Site code? How about I give you the number of dollars we've sent you, and then we can talk about how you can't find those other numbers in your system.
I went through this yet again earlier this week. At one point I had to bite my tongue to keep from saying, "Four months ago, my company wrote you an eight-figure check for worldwide licensing and support. If that's not in your database, maybe you should switch to Oracle."
Too bad they didn't go the other way too: us.konicaminolta.com, uk.konicaminolta.com, etc. Were I registering domains for a big company selling to consumers, I'd register anything they might reasonably guess. (Plus use geolocation to guess for them.)
OTOH, people use Google (etc.) so much that the actual domain names almost don't matter--just click on what Google found. (I still can't remember our public library's convoluted domain name even though I go to the site a couple times a week.)
I've had the same experience with disks. I've had brand-new drives fail in under 200 hours of use, and I have 20-year-old 1GB drives that are built like tanks and still work fine, even though they make that irritating buzzy bearing noise.
RAM disks are cool and all, but except on live CDs they're usually unnecessary. The kernel's buffer cache and directory-name-lookup cache (in RAM) can often outperform RAM disks on second reads and writes.
(Claimer: I worked on file systems for HP-UX, and we measured this when we considered adding our internal experimental RAM FS to the production OS.)
Slashdot Mirror
Show me where I said that sysadmins were the only one this happens to.
Please don't confuse system administration with staffing a helpdesk.
Just because you don't like dealing with unreasonable jerks doesn't make you unfit for a job where you occasionally have to deal with unreasonable jerks.
And for all of you following this thread: For every one of the incidents I mentioned originally, there were hundreds where users' problems were solved without incident, where infrastructure problems were solved without the users even knowing it, and where everybody involved said "please" and "thank you". For every 4:30pm Friday (non)emergency, there were hundreds of cases where people asked well in advance for things they knew it would take a lot of effort to provide. For every person who filed a ticket saying nothing but "I have a problem--call", there were hundreds that spelled out their requests in enough detail that the only thing I had to say back to them is, "It's done."
Especially gratifying were the times I announced a new capability, and had people ask how I knew they were going to be needing it.
Don't make this about me, personally. If you think from what you've read here that I'm a lousy sysadmin, or horrible to work with, don't hire me. But it's not just me. Every one of us has to deal with sysadmins, administrative assistants, procurement departments, IT desktop support people, our own bosses, and all the other people out there whom we ask for things in order to get our jobs done.
Ask nicely.
I like that. Another question that gets surprising results is, "What problem are you trying to solve?"
At the particular job where all this happened (2003-2010), I was on a defense project with about 750 engineers across seven development sites. At ours, I supported about 130 people. At every other site, regardless of size, what I did was done by at least three full-time staff. I actually got pretty good at all the things you claim I can't do, from prioritization to automation to virtualization. Pretty much anything that happened more than twice became a documented procedure, as did many things that never happened at all but I still planned for. My lab got audited internally or by the government three times a year without a single finding, and some of those procedures got recommended as company-wide standards. There was never an instance of data loss. No deliverable was ever late due to lab issues. The infrastructure I built out was intended to be adequate for three years but lasted through the end of the project.
My value to the business? That was measured quantitatively by project management: We had two extra full-time engineers working on revenue-generating deliverables because of what I was doing by myself instead of with two other sysadmins, one more because of what I saved in hardware and software costs, and 2.5 more across the project because of process improvements I developed that were implemented project-wide.
Was I the best sysadmin ever? Of course not. I made lots of mistakes, and when I did, I owned up to them. When I behaved inappropriately (and don't tell me you never have) I apologized publicly to the people involved. And, unlike your posts, I never had to resort to swearing, mocking or name calling. Or is that somehing you do only behind the safety of your computer and your anonymity?
When did I ever say I didn't know how to handle those situations? I was just pointing out some of the more, um, challenging aspects of the job, for people who think systadmins are all Dennis Nedrys.
I'd sure like to know who all these ACs are who seem to know my job and the people I work with so much better than I do.
I'd aso like to know where in the multiverse there's a sysadmin who has the time and resources to automate every possible sequence of things a user might need to do, including users who are running experiments, doing one-off concept studies, having their requirements changed at the last minute, operating under crushing deadline pressure, and the like. Everything my users do, I've done. I've been every one of them at some point in my career. The kinds of assholery I describe are things I don't do to sysadmins, coworkers, even PHBs.
In any case, you're making my point: Follow me around for a day, and see if it's all really as simple as you're making it out to be.
If there weren't good parts of the job, we wouldn't do it. And the majority of users aren't lusers. There are some who we'd lay down in traffic for, because they understand our jobs are hard and thank us for what we do for them, not just by saying thank you but by making their requests clearly, giving us reasonable notive if the work is non-trivial, giving us reasonable time to do the work, and only calling something an emergency when it really is.
A lot of he time we just happen to be the one they blow off steam to when something out of their control makes their already bad day worse. I could have handled the 15-minute screamer several different ways. I could have stopped him after 15 seconds and told him how to file a ticket, except that he already had, both with me, and with the networking people. I could have told him to lower his voice or he'd be picking up his teeth with broken fingers. I could have turned my back on him mid-rant. What I did do was realize that this was nothing personal, let him scream himself out, then went back to waiting with everybody else for the network people to get the network running again.
Oh and to add to your Sysadmin 101 bullet points:
Make them want to file tickets by responding quickly and then using the ticketing system to communicate your progress in a timely fashion. Make sure the ticketing system is DEAD EASY to use--with ours, users never had to do anything more than send mail to help@oursite.ourcompany.com. Unless your job requires that you take requests over the phone or in person, don't.
Always remember what my wife, also a sysadmin, says: "Our job is to make the users productive, not to make them happy." Make them happy as much as you can (which is most of the time), but not at the expense of making them, or others, less productive.
No, sysadmins do NOT train new employees on company policy, HR does. No, sysadmins do NOT train new emplyees on basic computer science, college does. No, sysadmins do NOT train employess on the internals of the products they're working on, other developers do. No, sysadmins do NOT train new employees on how to boot Windows, edit a Word document, fire up a web browser, use a mouse, etc., their kids do.
Yes, there are things that sysadmins provide new employees: Things like which servers do which things, how to get access to the various systems necessary for their jobs, the names and locations of printers and network shares (and thir Unix/Linux equivalents), where to find things out that we don't (and often can't) tell them, how to file trouble tickets. But we are not supposed to be the first person the new guy comes to when they have questions about everything from how to set up their 401(k) deductions to where the best restaurants are.
I was thinking of a particular person at my last job. He'd work 48-72 hours, go home, sleep, then come back in and do it again. This was not a death-march project, and we had only about six weeks of real crunch time a year. Every now and then his management would try to get him to work saner hours; he'd take weekends off for a month or so, then get back to the old ways. He was brilliant, personally a pretty nice guy, shared his knowledge instead of hoarding it, and was a real asset to the project. We were just afraid he'd eventually burn out (or flame out), and we felt bad for his wife and kids.
#2: You have to tell the doctor *where* it hurts, not just *that* it hurts.
I have a simple solution: Follow me around for a day (and a night).
Watch what happens when two people, either of whom could fire both of us, issue demands that are diametrically opposed and mutually exclusive.
Watch when the new guy gets ignored by his team members and forgets that Google exists so he comes to us expecting days of basic training on how to do his job.
Watch when the workaholic engineer expects us to be there around the clock for everything from new machines to coffee runs as he compulsively works his 72-hour shifts.
Watch when we spend six hours fixing a machine somebody botched horribly because we told them to push button A then button B then button C, but they pushed button B then button A then button C. For the third time.
Watch when Mr. Hot Temper screams at us for 15 minutes because the network is down, even though not only are we not permitted to do anything with the network, we're not even allowed into the wiring closet.
Watch how we're never thanked for anything, but we're informed on a regular basis as to what people think our mothers did for a living.
I could go on, but rest assured, you'll want your own job back.
OK, here's the slightest failing I've felt numerous times: Old laptop whose graphics under WinXP were just fine, if a little slow. Install Linux with your favorite desktop (LXDE works best for me on that machine). Machine is under moderate load. Click and drag a window to move it. When you release the mouse button, the window is still following the cursor, because the mouse-button-up event was not handled properly.
JWZ complained abut this sort of thing (events not being presented to the handler in proper order) when he was working on the Unix/X version of Mozilla. ISTR him saying that it was a problem wih the protocol itself, which would explain why the problem persists almost 20 years alter.
We know about GNU/Linux and GNU/Hurd. ISTR someone cobbling together a GNU/BSD at some point. Any others? GNU/Solaris? GNU/HP-UX? GNU/DR-DOS?
Talk about bricking your device!
The same thing happened with HP/UX 9. HP tried all sorts of things, including free consulting to get customers to upgrade to 10.x, but the don't-fix-what-isn't-broken crowd kept driving their dump trucks to Cupertino. They finally ended it by pointing out that there was no way to make it Y2K compliant without breaking backwards binary compatibility.
And if you think they will, look at when Microsoft originally wanted to EOL WinXP, and when they actually did.
I just took a 21" CRT to the recycling place. In 1995, it cost about $2200 new. In 2001, my employer gave it to me as scrap when our building was closed and they decided that a lot of that stuff was cheaper to give away than to move to some warehouse across the country. (Plus it was a tiny bit of good will that the local management could show the laid-off employees when the Big Guys were being callous pricks kicking us to the curb while we were still going to 9/11 funerals.)
ObTopic: $400 is an expensive monitor these days, but it wasn't that long ago that $400 wouldn't buy you a useable SVGA monitor.
Send it to me. I wouldn't mind having a headless <5W NIS server for my home network.
It is when you run old clunky hardware like I do. LXDE runs very nicely on my ten-year-old Dell C640 laptop.
Too true. 6500K CFLs are so "cold" looking that they make me shiver.
The problem I have with Crees is th form factor. We have recessed lighting in our kitchen, mostly R30, and the fixtures are 40 years old, certainly superseded by newer standards. Regular R-30 bulbs fit perfectly. The Cree equivalents take some work to fit right, especially the ones with the built-in bezels.
That said, I love the light they produce. It's a bit brighter, and only slightly whiter than the light the 65W incandescents put out, at a fifth the power consumption.
I have one question for the pick-your-color manufacturers: Have you ever consulted an interior designer? The colors of paint, fabric, etc. in a room are all picked with specific lighting in mind, both natural and from lamps. Start futzing with it, and things will start looking crappy. Ever wonder why a hotel room looks fine under CFLs but the same CFLs in your bedroom make everything an ashy grey? It's because the colors in the hotel room were picked specifically because they complement the color spectrum put out by the CFLs.
I'm looking forward to the day not far off when I can have all LED lighting in the house, but I have no desire to make radical color changes (except for special applications people have mentioned ike aids for the deaf).
IBM support still sucks. You spend more time proving to them that you're entitled to support than you spend getting support. Customer number? Site code? How about I give you the number of dollars we've sent you, and then we can talk about how you can't find those other numbers in your system.
I went through this yet again earlier this week. At one point I had to bite my tongue to keep from saying, "Four months ago, my company wrote you an eight-figure check for worldwide licensing and support. If that's not in your database, maybe you should switch to Oracle."
I see dead OSes. They're everywhere. They don't know they're dead.
Too bad they didn't go the other way too: us.konicaminolta.com, uk.konicaminolta.com, etc. Were I registering domains for a big company selling to consumers, I'd register anything they might reasonably guess. (Plus use geolocation to guess for them.)
OTOH, people use Google (etc.) so much that the actual domain names almost don't matter--just click on what Google found. (I still can't remember our public library's convoluted domain name even though I go to the site a couple times a week.)
And it persists. My kid's teacher's email address is @brrsd.k12.nj.us.
I've had the same experience with disks. I've had brand-new drives fail in under 200 hours of use, and I have 20-year-old 1GB drives that are built like tanks and still work fine, even though they make that irritating buzzy bearing noise.
RAM disks are cool and all, but except on live CDs they're usually unnecessary. The kernel's buffer cache and directory-name-lookup cache (in RAM) can often outperform RAM disks on second reads and writes.
(Claimer: I worked on file systems for HP-UX, and we measured this when we considered adding our internal experimental RAM FS to the production OS.)