MSDN is the developer stack. More stuff, but costs more too

Question to ask the telemarketer: "Is this really what you wanted to be when you grew up?"

Can this Mr. Jesus help me get to California?

"Level of trust"? Is that anything like John Glenn's quip about sitting on top of two million parts, all built by the lowest bidder?

So was my grandfather. He became an optician by answering an ad in the paper: "Opticians wanted. No experience necessary; will train."

Compare that to a typical job requisition today. It's kind of the inverse of CV padding. The list of must-haves is so long that no five mortals or two gods could meet them all.

"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.