Not too much to say about this one.
Just go read it.
Not too much to say about this one.
Just go read it.
Having been doing the sysadmin gig for awhile now, some things have become abundantly clear.
Friday was a reinforcement day for me on the second one above. Sometimes there’s nothing to do but bite the bullet and put time into the problem.
The positive from this was that I got the thing working for our customer.
The negative was the time away from my personal affairs.
The true take away for anyone just starting out as a sysadmin, IMHO, is that you shouldn’t be shocked when things go terribly, horribly wrong and you have to spend the night at work. It happens. Hardware will fail. Someone has to fix it or do the restores.
What *SHOULD* shock you is if this is the normal situation at your work.
For example:
When I decided that I was going to look for work, I applied at my current employer and another company that shall henceforth be dubbed DysfunCo. I had already interviewed with $employer and was talking salary before I went to interview at DysfunCo. The two gentlemen (PHB #1 and #2) that interviewed me are programmers promoted to management. The following is paraphrased excerpts of the interview.
PHB #1: “We’re looking for a sysadmin to help our developers any way they see fit.”
PHB #2: “It’s really important that the candidate enable our developers to keep their creativity going.”
Halfdime: “Can you give me an example of what kinds of things you’re looking for?”
PHB #2: “We really need a broad based specialist to help us liaise with our corporate headquarters.”
Halfdime: “What’s your relationship with corporate like?”
PHB #1&2 (together): “Oh. They HATE us.”
PHB #1: “Yeah, remember the dhcp incident?”
Halfdime: “What was that?”
PHB #1: “One of our guys was working on new appliance and he needed to have it be a dhcp server. So he plugged it in to the core router here and it started handing out leases on the wrong network. Everyone in the office was down for like two days until he realized he was the cause of the problem.”
PHB #2: “Yeah, those guys in corporate were pissed. Good thing they never found out it was us!”
What followed the numerous tales of what they allow to keep their staff from having their creativity stifled was embarrassing. When they finished and asked me what I thought I would do to help them out, I gave them an hour long treatise on how broken their organization was and that any sysadmin worth hiring would start by setting boundaries.
They didn’t call me back.
I’ve thought about sending them a bill for two hours of consulting.
The morbid curiosity in me hasn’t grown enough for me to reach out to my contacts there and find out how long the guy that DID take the job lasted.
If you’ve made it this far, I would like to wrap this one up with another thanks to my wife. She put up with the horrendous hours I had at my previous job every May through October and is as unflappable as they come. She keeps me grounded and reminds me of what’s really important.
Thanks for being patient honey. You rock!
It’s been quite some time since I first ran across Giving good report but from time to time, I come back to it just to keep myself in check.
If you’ve never read the paper, you should. [0] It’s by a gentleman whom I’ve never met named Richard Threadgill.
Basically, it is a plea to all technical workers to keep management informed about what they’re doing. For many of you, this may seem a simple concept but I’m pretty sure all of you know someone that is being described by this paper.
I’m lucky enough to have a boss that has been amongst sysadmins for a very (VERY [1]) long time and understands the oddities common in our profession. He’s good at extracting the information if someone isn’t good at giving it.
[0] Yeah. I just should on you
[1] I’m talking Multics old.
I got yer comments here...