While the vast majority of IT professionals I have worked with over the years are professional and competent, in the last several years I’ve met some most arrogant, lazy, and incompetent people I have the displeasure of ever meeting.
Today, I had a run-in with one of those people. And try as I may, I just have to rant, because I’m so disappointed that these people are able to keep their jobs.
Here’s the thing. When I first started my career (when dinosaurs roamed the earth), I sat on both sides of the fence – both in IT and software development. I ran backups, wrote code, reset passwords. I dealt with users. I know the pain of dealing with people who don’t know and don’t care.
Later on I moved solely to developing software and haven’t looked back.
Truth is, too many administrators are jerks. It wasn’t always this way. Here is a tiny sample of some of the idiocy I’ve had to deal with lately:
I was told if I plugged in my MacBook Air into the corporate network, I would be fired, because Apple wasn’t supported by IT. Never mind the fact that we were developing an iPhone application. Even after someone clued him into the fact that you can only compile iOS code with a Mac, he still stuck to his guns. I gave up and stopped brining my development laptop. In frustration, they attempted to outsource to iOS project overseas. A year later, the product still wasn’t released.
While developing an embedded device which ran Linux, I was told that Linux wasn’t supported and I couldn’t plug any Linux hosts into the network. When it was explained that we would need Linux to develop software for, um, Linux, the solution was to purchase every developer a second PC, which could only be connected to a “test” network, which wasn’t routed to the Internet. We resorted to having two NICs in the windows hosts, so we could copy patches and code to the Linux hosts.
When the IT guy found out about the second NICs, he flew into a rage and swore that having more than one Ethernet card in a PC would cause it to bridge the two networks together. Fortunately, he had lost all credibility by this point.
Additionally, while he was hunting down a rouge DHCP server he spied that we had Linksys switches in our cubicles. Another IT rage ensued. The solution to the imagined problem was to throw away every purchased switch, and purchase every single developer a cisco rack mountable switch.
But nothing can top what happened today. I’m working at a large multi-national corporation. I was developing code on CentOS 6, but my manager wanted me to install and use a customized RedHat Enterprise kickstart image on a server, created by “IT.” Before I continue, let me say that the butchered RHEL version is already end of life.’
While the CentOS image installed without a problem, the RHEL image had a multitude of problems from the get go. They had patched the system to authenticate against an active directory server (that worked), and mount NFS shares over the system directories (that didn’t work). Unfortunately, the IT guys needed to tell the NFS server that my new server was authorized to mount the file shares.
An easy fix.
Three days later, I get a call from the “unix group.” The voice at the other end of the line was shaky with agitation. At first, I thought maybe I was too verbose on the IT request. However, it became clear that he had no intention of investigating the problem at all.
We don’t support that hardware, he explained. He rattled off a very small list of supported hardware, all Dell PCs. He inferred that we should toss out the Dell rack mount server and purchase a supported dell tower PC. The hardware is identical to the workstation.
I was simply stunned. What did the hardware have to do with DNS and NFS setup?
I fired off an email suggesting that I could help show the “unix group” guy how to configure the services if he needed help. I sent the helpful email before I even thought that the unix guy might be insulted.
A terse response came back with over a half-a-dozen CC’d managers. My team lead diplomatically scheduled a face-to-face meeting with some IT people.
In the mean time, I had access to a blessed tower configuration with the OS installed. When I started to upgrade some of the packages, yum threw out thousands of errors when I tried to verify the yum repository. Turns out that someone decided it would be a great idea to point yum at the CentOS repositories and updated most of the packages from there.
Yes, they were paying thousands of dollars for RHEL licenses, and were running CentOS servers.