"Quiet cubicle"? I have never experienced this phenomenon.

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.

I shot freelance for a newspaper in Toronto during the 80s and 90s. And although the work was a lot of fun, I think its time is long over. Consider the adage from dead tree papers: If it bleeds it leads. How many different, artistic ways can you shoot the following, that hasn't been done a zillion times in the past:
1) Large or medium-sized structure fire--this was my specialty.
2) Personal injury accident.
3) Victim(s) being transported.
4) Reminder to set clocks ahead/back.
5) Look how Hot/Cold/Snowy/Icy the weather was yesterday!
6) Perp walk or subject under arrest.
7) Politician making a speech on in a media scrum.
8) Drug/weapons seizure evidence on the table.
9) Presentation of a giant cheque to a lottery winner or charitable .org.
10) Devastation after a large natural disaster, governor/official doing official tour
11) Sad kid/parent after a bully stole their lunch money, bicycle or all the toys for Christmas presents at the poor house.

Now. Go fetch today's paper (good doggie!). How many of the above items do you see in the hard news section? Now factor this: If it's a major disaster, fire, accident, etc, the news editor will be fielding calls from hundreds of people with photos of the event. Probably some with pro-sumer levels of kit. If that isn't available they'll buy a wireservice image and run it. Everything else mentioned is shootable with a phonecam or a shirt-pocket cam, and the level of knowledge needed to shoot it is somewhere between "f/8-and-be-there," and "push-here-stupid."

Sports is an entirely different kettle of fish, and I don't know how they're going to handle Bulls/Black Hawks/Bears/Cubs/Sox games. Again, probably just buy freelancers' materials or stuff off the wires.

Gone are the days when a newspaper NEEDS actual photographs. Unless you're living under a rock the audience already knows what the governor looks like, what a perp-walk looks like, a building fire, a traffic accident or the President making a speech. We can get that anywhere. The hard news reporting is what I care about (not that there's all that much of it these days). Pretty pictures I can find online. They made the right call.

But that is what the new nyc machines are. Paper ballot, pen, paper, and a scanner, but the voters and poll workers still have not figured it out. They make you wait on line to find out which line to wait in to get your ballot, then wait on line to get the ballot(and sign for it) the you have to fill it in where they can see you, but not your ballot, then you bring it to the scanning area, and the whole process takes more Room than the lever machines and walking from point a to b. last election, we had lines around the block to get into get your ballot, and with the levers, I never had more than 5 people in front of me

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?

depending on where you live, even in the US, you want to build an addition to you house, go right ahead. a lot of the country does not have zoning laws