Work

In the little over seven years that I've been employed at my present job, I've had a total of 14 managers. That's nearly one every six months. Each time I got a review from a manager, I was told how exceptionally well I performed and how it would be impossible to do what we do without me (or something to that effect). Typically, this was true.

During my tenure, some managers gave me good bonuses or a raise here and there. Other managers didn't. Some managers were complete assholes or total bitches and others were great people just trying to do right and not lose a limb (or their head) in the process (though a few still did).

Usually, it took about a month or two to train a new manager on where I was, where I'd been, where I was going, and how fast I'd get there. Generally, most managers were only able to deal with one or two of those variables. The more important thing, in their minds, was making sure they looked good to their managers. Somehow they forgot (or never knew) that well cared for, productive employees can make any manager look good to their boss!

In the next month or two, my manager would learn how many little, behind the scenes things I was doing to keep the automated orchestra playing flawlessly. Slowly, they'd understand the necessity of a good SCM engineer and start to put well placed trust in me. Anytime I thought it might be nice to venture out into something different (like development, or project management, or marketing), I'd bring it up with my manager and usually be give "20%" of my time to work on new tasks.

Inevitably, releases come, then patches, coupled with constant tech support to my group of developers, and of course, myriad regular SCM duties. The "20%" of my time dwindles down to an effective 0%!

So, after all this time. I've left my company for another. As I embark on solving a new set of challenges, I'll try to remember the lesson learned from my last seven years of work:

Don't be irreplaceable, if you can't be replaced, you can't be promoted.

I'd always thought it would assure the consistent availability of my position were I to make myself irreplacable. Indeed, I spent a considerable amount of energy to ensure it took me to deliver our prodcts. Well, there is no doubt my efforts certainly ensured my position, but the side-effects were so restrictive as to be stunting. I've glad I've broken free of that suffocating situation.

I'll apply what I've learned to my future endeavors.

I was a little concerned with the web service on my new Intel Xserve running Mac OS X Server 10.5 (Leopard) when I started seeing the following log entry in my Apache error log:



I wasn't so much concerned that there was a critical error. I could see my Apache 2 based Subversion server (DAV svn) was performing just fine. My larger concern was that there was an error about mod_rewrite when I wasn't the one that turned it on in the first place. You see, I could believe it was my human error that might have caused the problem but I'd have a harder time believing it was a problem with the default install.

So, I looked at my config file: /etc/apache2/sites/0000_any_80_.conf and compared it to the default config file: /etc/apache2/sites/0000_any_80_.conf.default and found the <IfModule mod_rewrite.c> containers to be exactly the same. Annoying.

Iquickly gave up trying to point the finger and lay blame and decided to take the initiative to fix the problem. I fixed it by giving mod_rewrite an actual log to write to (make it happy - if for only a moment) and then told it to not to log anything to the file (mwahahaha). The change was simple.

From this:

To this:


Problem solved it seems. Now why did I have to do this!?

I just got two brand new Xserve build machines and the first thing I did was wipe out the default Tiger OSX Server install and install Leopard OSX Server instead. That wasn't too bad except for the fact that I had to go through the setup assistant first in Tiger before being able to boot off the Leopard disk, wipe the drive and install.

After I got Leopard OS X Server up and running on the Xserve, I tried to ssh out from a user account to another machine (my source repository server) that's running 10.4. While establishing communication, ssh had this huge delay (more than a minute - I think). I had to figure out what was going on so I ran ssh -v to get the verbose output from ssh while it was connecting.

The verbose output showed this.

debug1: Unspecified GSS failure.  Minor code may provide more information
Server not found in Kerberos database

debug1: Unspecified GSS failure.  Minor code may provide more information
Server not found in Kerberos database

debug1: Unspecified GSS failure.  Minor code may provide more information

So, I went spelunking in and ended up comparing the /etc/sshd_config files on both the local (Leopard Xserve) and remote (Tiger source repository) machines. I found on the remote machine (Tiger source repos) that Kerberos authentication was turned off by default but commented out.

So, I changed this:

# Kerberos options

# GSSAPI options
#GSSAPIAuthentication no

to this:

# Kerberos options
KerberosAuthentication no

# GSSAPI options
GSSAPIAuthentication no

in the /etc/sshd_config file on the remote (Tiger OS X server) and reconnected via ssh without a problem. Then it was on to more work setting up my new xserve build systems.

My manager today decided to cancel all of her current one-on-ones including mine (I prefer to call them one-to-ones - so they don't sound like a wrestling match). She noted that she'd setup "quarterly goal review 1-1 focused exclusively on career development" and that she would "work with each individual to determine whether a weekly 1-1 is appropriate."

It's amazing that managers, whether new or seasoned, don't fully grasp the importance of one-to-one time. In here defense, she does have around 17 direct reports now - but that's a failing of her managers. I thought about sending her the Manager Tools link to their podcast on "the single most effective management tool - the one-on-one" but I figured I'd look like I was telling her how to do her job. Obviously, that wouldn't go over too well. Maybe I could leave an anonymous note with the link to Manager Tools on it...

Instead, I think I'll listen to the podcast again myself and the next time I talk to her, (probably at my quarterly one-to-one) I'll try to bring up some of the points Mark and Mike make. Also, I think I'll privately review (and possibly fill out) the Manager Tools: 1-on-1 Key Points and Prep Form (PDF). After I've done that, I'll start looking for a new position. I don't have time for inattentive and overburdened managers anymore.

I started working for a new group around mid-September and inherited an old (5 years or so) shell-script build system. Most of it is in KSH (I really prefer BASH) but alot of it is so poorly written and thought out that I have a hell of a time trying to fix/enhance it. Every time I need to do something to the scripts I oscillate for an hour on whether I should try to work my change into the existing script or just take the time to re-write the whole thing!

I was Googling today for some thoughts about writing shell scripts and found a great article about writing robust bash shell scripts. While I don't use everything mentioned in the article, I was happily surprised to find that I do use more than a couple of them.

Of course, one reason for my irritation with the system I've inherited is that it doesn't use any. Before working in this group, all SCM infrastructure I'd done was built ground up by myself. I feel for those poor developers that get stuck trying to enhance old code now that I've really gotten a taste of how hard it can be. I imagine there is alot more nasty build system scripts out there than there are good ones but I'll certainly try to even the odds a bit by making my scripts as robust, readable and commented as possible.

Hopefully someone who comes three or four years after I'm one will be pleasantly surprised when they have to add something to my scripts!