mainframes and sex
Sep. 24th, 2010 11:17 pmMaybe it is insanity.
I mean, I am the only person in our team who has any mainframe-based skills and what did I suggest to my manager today? I proposed converting our last remaining mainframe-based process into a unix one like everything else our team owns. Basically I am making one of my skills obsolete. On the other hand, it’s not as if they keep me onboard because of that unique knowledge. The last time I had to do maintenance to that process – which I created 15 years ago – was in June 2007. That thing never breaks – as is usually the case with my work – and I seldom use those skills except twice a year, when all mainframe-based processes must prove that, should something happen to the Big Machine, they could switch to a backup. Like sex, those exercises involve a lot of preparation then “Boom!” it’s quickly over, but without the fun that usually ends the Other Activity. This process will be shut down some time in 2012, possibly after the End of the World. Why then bother? Why not leave things as they are for the next 2 years?
I’m bored.
I look back upon 2010 and most of what I did was to provide support to the contractors working on our merger, or keeping the system alive, or transferring most of our unix-based processes to new servers in another data center. I am quite good at working in the engine room.
In other words, I have done very little creative work.
And there will be a lot of that here. The conversion doesn't mean keeping the existing logic as is while translating one computer language into another. I will instead translate the logic itself to take advantage of a different technology.
I mean, I am the only person in our team who has any mainframe-based skills and what did I suggest to my manager today? I proposed converting our last remaining mainframe-based process into a unix one like everything else our team owns. Basically I am making one of my skills obsolete. On the other hand, it’s not as if they keep me onboard because of that unique knowledge. The last time I had to do maintenance to that process – which I created 15 years ago – was in June 2007. That thing never breaks – as is usually the case with my work – and I seldom use those skills except twice a year, when all mainframe-based processes must prove that, should something happen to the Big Machine, they could switch to a backup. Like sex, those exercises involve a lot of preparation then “Boom!” it’s quickly over, but without the fun that usually ends the Other Activity. This process will be shut down some time in 2012, possibly after the End of the World. Why then bother? Why not leave things as they are for the next 2 years?
I’m bored.
I look back upon 2010 and most of what I did was to provide support to the contractors working on our merger, or keeping the system alive, or transferring most of our unix-based processes to new servers in another data center. I am quite good at working in the engine room.
In other words, I have done very little creative work.
And there will be a lot of that here. The conversion doesn't mean keeping the existing logic as is while translating one computer language into another. I will instead translate the logic itself to take advantage of a different technology.