I live by a few basic laws, one of which is, "Everything works on paper." Sometimes, all the IT governance and change control that an Information Technology Infrastructure Library- (ITIL) and agile-trained project manager offers isn't enough to deal with all the contingencies of system administration. The number of variables is too great. Sometimes, the number of dependencies is overwhelming to the point of boggling the most spotless of minds. Sometimes people make mistakes. Still, we march forward with the zeal and determination of a true warrior, never admitting defeat, googling until our fingers are sore, reading forums until our eyes bleed, and arguing our points in a few subreddits for good measure.

In the early days of the pre-Google Internet, I was updating systems one starry evening, hopped up on Diet Dr. Pepper and pepperoni pizza, when I got an error I couldn't get past. I tried several things to bypass the fatal error preventing my progress. Something was missing – a dependency, a permission, a setting, or something I couldn't pinpoint. I even resorted to searching Yahoo for an answer. Sadly, none came. The body of knowledge that exists now didn't exist at the time, and I was stuck. I had to back out all my changes and email my manager that tonight's maintenance had failed. I knew that the next day wasn't going to be a pleasant one for me.

In those days, it was common for managers and senior staff members to call out junior members as incompetent or, worse, to label them "clueless newbies." I took the instructions home to study them carefully again to see where I could have made a mistake that disrupted my entire evening of patching bliss. I found no such error.

I braced myself as I walked onto the floor and headed to my cubicle, hoping not to see anyone until I arrived safely. I made it, but the phone rang to summon my presence almost as soon as I logged into my workstation. My manager obviously received messages when his staff members logged in. Can you say "micromanagement?"

"So, how'd it go last night?" came the rhetorical query that forced me to admit my failure. "Not good," I answered. "I had a problem here in the instruction." I highlighted the failure point on the sheet of paper where I'd scribbled a few notes to document what I'd done in response to a couple of system messages that I didn't recognize and didn't have time to Yahoo!. My manager was already picking up the phone to summon over a senior member of the team. Chris was the senior guy and everyone's guru. You went to him when you needed tools, software, hardware, or the vast occult and ungoogleable knowledge of the Windows operating system. "Hey, Chris, can you come to my desk for a minute?" He appeared quickly to begin his "I know more than you do" assault on my already damaged psyche.

I reluctantly handed him my instruction sheet while he sat down to study what I'd done. He said, "Good notes." I never lifted my gaze from the floor and said, "Thanks." He continued his ponder. After a few minutes, he looked at me and then my manager and stood up, saying, "There's a step missing in the instructions I gave you. I'm sorry. I skipped the step where you should've changed the address of a memory block."

You see, in those days, with Windows 3.11, we had to alter "upper" memory constantly and do a lot of remapping to get everything to work. We used the Quarterdeck Expanded Memory Manager (QEMM) OPTIMIZE utility, but that was only a start. Because of our many drivers, you often had to go in and remap specific areas to maximize the other 384KB of available RAM, above the base 640KB worth. He forgot to mention the remap and address space I should have used. To my surprise, he admitted it – freely and without coercion.

The point of this story is that even if you follow the instructions, abide by every rule, and rely on your knowledge and experience, sometimes things still go wrong. Don't beat yourself up for it. Don't allow anyone else to beat you up for it. There's always another maintenance window awaiting you.

Ken Hess * Senior ADMIN Editor