Archive for May, 2012

At the end of my third week in the new job, I’ve come to a couple realizations. Most recent is that I’m having to watch the clock closely so that I leave on time. I’m a contractor, so I’m hourly, not salaried. That means it’s all too easy for me to start putting in overtime at a job I enjoy, and this i just such a job. Problem is, the manager here isn’t allowed to give me overtime without the approval of his higher-ups, and unless something major goes bonkers that approval probably won’t be forthcoming. This sort of bugs me, because I’ve already found myself wanting to stay later and get something finished, but it’s ultimately not that big an issue, I just have to budget my time closely.

I’m also re-discovering why I went in to IT in general – and system administration in particular – in the first place. I’m having a large influence on how things are done already, making people’s lives easier and helping them sleep better at night. At least, I think I am, which is much the same thing as far as my enjoyment of the job is concerned. I’ve also already been given opportunities for input that my former boss would have never given me, and made decisions he would have never approved of simply because he didn’t understand the logic behind them (or was too caught up in having to appear in control of everything to actually let anyone else get any work done).

In future posts, I may detail some of the automation stuff I’m putting into place. It’s not really all that ground-breaking; honestly, it’s somewhat pedestrian and rote, simply because there are so many other places that have done similar things before. Still, it’s all my stuff, customized specifically for my new job, and I take a great deal of pride in the fact that not only did I put it into place, but that it’s been well-received by the admin team here and that it has (so far in it’s limited lifetime) worked quite well. Not flawlessly, but quite well.

I’ve still got a good bit of work to do to add functionality I want to add to what I’ve already put in place, but I’m going to launch by next big initiative next week, addressing a completely different topic than workflow automation. It’s something I see as sorely needed (again) for the future of the environment, but it’s significantly larger and more invasive than the simply installation automation I’ve done so far so I don’t know how well it’s going to fly. I have faith that the people here will see the need for it and the logic behind it, I just don’t know how easy it will be to actually make the necessary changes to put it into place. I’m hopeful.

Wow. That’s something I haven’t been able to say about my job for a long time. It feels really good to be able to say that.

When I started the new job, I knew I would have a lot to learn. I have learned a lot, and I still have a lot more yet to learn. One of the things I have learned is that there is very little in the way of formalized process-oriented infrastructure here. System builds are done effectively the way they were done at my last job (which I wanted to fix but wasn’t ever given time or permission to fix) – which is to say, by hand with an instruction sheet nearby.

Lots of things are hand-copied around, or schlepped around using a script that does the equivalent of an scp then an “ssh root@<server> mv”. Formalized? Heh. Process-oriented? Right. Auditable? I can hear the paramedics yelling for defibrillators now, and the auditors haven’t even gotten here yet.

One of the things I wasn’t sure of was how many waves the company wanted me to make. Should I sit down, keep my mouth shut, and do it their way? Should I offer small changes to establish myself, then sit down and shut up? Or should I go all-in and make as many waves as necessary to fix things up and get them running right? In other words, am I supposed to be a quietly competent consultant, or a bombastically loud deity of a consultant?

Well, neither – they’re both too extreme. But much to my surprise, the company wants me to make waves. Lots of them. They want me to discuss things first, but if I see something broken, they want to know of my desire to rip it apart and fix it, and so far they have let me rip away. There’s one bit I’d love to rip out completely and redo from scratch, but it’s far too ingrained in too many areas for that to be an easy extraction, so I’m letting it stay in and just going to open a longer-term discussion about it.

But oh what glorious fun it is to tear apart and rebuild an entire infrastructure… especially when I’m so good at it, and it’s ultimately so easy! Yes, I said easy – it’s complex, but the complexity is due to size of the task, not difficulty. Hot diggity, I’m back at work!

I’ve been at the new job for a week now – today starts my second week. I’m really enjoying this new gig so far – I’ve already had a pretty big impact on how RHEL installs are done, and that project isn’t even as fully complete as I’d like yet. I’m already comfortable with the new way of doing things, and I think I’m about to get official blessings to roll out a new package build system, which in turn will get integrated with the Satellite for package deploys. That will take a few weeks to complete, and that’s just the beginning of what I want to do here.

Not only that, but my coworkers, and in particular the lead UNIX admin here, have already repeatedly demonstrated just how much better they are at both technical and interpersonal matters than my last boss. I made a typo yesterday that took me and the lead admin about 30 minutes to figure out, and he told me he would “correct the problems caused by PEBKAC”. Not only does he know what PEBKAC means without having to look at the (mostly erroneous) definition in Wikipedia or Urban Dictionary, he actually uses the term correctly! My last boss (supervisor and boss, really – and yes they were separate people) had no idea what the term even meant, then when I explained it to them, and explained how I used it, told me I was wrong. Umm, excuse me, I am not wrong about how I used it, you are wrong for not knowing popular well-known slang from the industry you’re in.

Well folks, it’s been a bit since my last post. In the interim, I have left my last job (thankfully) and started a new one.

Why thankfully? More on that later.

The new position is really awesome. The guys I’m working with are on top of their game, and although I’ve already come across some things they do in certain ways that confuse me, sitting on my initial reaction has let me realize that the way they do things makes sense. It’s not the way I would have set things up, but it works – in some cases, better than the way I would have set things up – and they are really good. I see a couple ways I can have a big impact, and I’m really looking forward to it. I’m not at all interested in becoming the next heir-apparent, or even some sort of team lead – I’ve been down that path and I’m not sure I want to go down that path again – but I do look forward to being closely involved and working with people who I respect and who demonstrate that they know just as well as I do how things should work.

So why am I so thankful? Well, aside from what I’ve just mentioned above, my last manager was… significantly less than fully qualified on a technical basis. Let’s just say I consider him to be a perfect example of the Dilbert Principle and leave it at that. My new manager is proof that every rule – including the Dilbert and Peter Principles – has exceptions, and I couldn’t be happier about it.

Hopefully I will be able to update this blog regularly, although if you go on my previous performance, you probably shouldn’t hold your breath.