Slashdot Mirror
Dirty Duty On the Front Lines of IT
snydeq writes "Jobs may be scarce in today's economy, but there's no shortage of nasty IT work — as the third annual installment of InfoWorld's Dirty IT Jobs series demonstrates. From the payroll cop to the coolant jockey to the network sherpa who has to squeeze into rodent-filled spaces and deal with penny-pinching clients, these seven jobs provide further proof that dirty duty abounds on the front lines of IT."
The hardest part of Andrew Bonar's job is convincing the world he's not a spammer. It's not easy. Just having "email deliverability consultant" on his business cards is enough to start the Viagra jokes.
Somehow I don't think Andrew Bonar's job title is the reason for the Viagra jokes.
I fix the horribly shitty code written by offshore Indian "developers".
The crap and stupidity I encounter from them daily is far worse than dealing with rodents, or cramped spaces, or spending months on the high seas.
If anybody thinks their IT job is dirty, they are sorely in need of a reality check.
I have relatives that run pig farms.
I've gone through my share of cluttered closets, dusty vents, underneath dirty desks, and cleaned the fluff off of old computers.
However, nothing makes me feel dirtier than installing Windows Genuine Advantage, as part of the new computer deployment checklist.
Can someone please call an ambulance? I think these sentences may have caused my head to explode.
Dislike the Electoral College? Lobby your state to join the National Popular Vote Interstate Compact.
So, is it cheaper to hire idiots to write most of the code and then hire someone smart later to fix it?
"The geek personality is very different," says Bectel. "I've worked in a lot of different markets, and techies have much higher expectations for coverage than virtually any one else. It's because they're so passionate about what they do, and they expect everyone else to be equally passionate about it."
The one line explanation of /.
I'm a consultant - I convert gibberish into cash-flow.
> So, is it cheaper to hire idiots to write most of the code and then hire someone smart later to fix it?
Doesn't the question answer itself? What's cheaper in the long run - install plumbing and wiring *while* the house is being built or afterwards?
Leave the gun, take the cannolis.
...you're asked to throw a 'TM' after a product name, only to find out later it's not really trademarked
Slapping that TM after a product name does trademark it, unless some direct competitor has already trademarked that same name first.
Only the (R) (for Registered trademark) has to be...well, registered.
If, as the article relates, Jennifer Hoffman had to call the data center and walk them through the process of manually restarting the one, single, solitary payroll server, a few items come to mind:
1) The people doing the upgrades without considering their impact should be shot on sight. Anyone who has worked more than a week in a network environment knows, or should know, that when you are considering an upgrade to anything, you have to find out who else is impacted by the upgrade.
2) Relying on said single, solitary server for payroll is just begging for disaster. For a highly critical task such as payroll, having one point of failure is beyond stupid. One deserves what one gets if the server dies.
3) The person who was fired but was still able to log time so they got paid was smart, the people who administered user accounts and security were not. Basic rule when someone is fired/let go/whatever is you disable their account. Immediately. Whomever in IT let this little gem get by should also be shot.
4) Having only one person who knew how to run the payroll software was, like issue 2 above, beyond stupid. Does no one use the bus principle any more? For the uninitiated, if someone gets run over by a bus, can they be replaced by someone else with minimal downtime? Are their tasks documented? What about quirky procedures that need to be done?
These are just basic questions I had when I read that job. My other question was, what company did she work for so I can introduce myself to them as a "Risk Mitigation Specialist"?
We will bankrupt ourselves in the vain search for absolute security. -- Dwight D. Eisenhower
"IT" is, as you say, a very broad term, so there is nothing at all unusual or problematic about having Real Serious Software Engineers, PhDed computer scientists, and basic server screwdriver monkeys under that heading.
Take the analogy of "Public health": Public health means MDs, and PhD epidemiologists, and biochemists and stuff; but it also means the sweaty guy with the pipe wrench who makes sure that your water comes up your water pipe, your sewage goes down your sewage pipe, and the two don't get confused on their way to your mouth. Same goes for the dubiously literate kid at McDonalds who checks the core temperature of the "beef" patty because the pictograms in the employee handbook told him to.
Obviously, any screwdriver jockey who calls himself a "hardware engineer" just because he replaces dead hard drives when the SAN LEDs change color to tell him to needs a smacking. As does any ITT Tech Java monkey who calls himself a "software engineer". However, the idea that "IT" consists exclusively of upper-echelon engineering experts is transparently silly. A huge percentage of the labor involved in making a real-world IT system run basically has little or no relationship with hardware or software engineering at all.
If you can re-write what they spit out as a support function, you are working too cheap. And of course the company's accounting system is worse than the State of Arizona's. Which is bad.
What you just said was also 'I can do it as well as they can, all by myself, within a support timeline'. So you and/or your boss are not selling your abilities either. But that's another topic - how do you sell to management what they aready have? Imagine the hilarity when they realize they paid twice for the project, and one of the costs is already in the house...
deleting the extra space after periods so i can stay relevant, yeah.
If an educational institution can't afford monopolyware then PIRACY is not the answer. If they can't pay their own way helping perpetuate the Microsoft monopoly, then perhaps they should not help perpetuate that crap to begin with.
A kid doesn't need to learn the Brand X version of a particular sort of software.
That's just nonsense perpetrated by middle aged idiots that couldn't adapt to something new if their life literally depended on it.
A Pirate and a Puritan look the same on a balance sheet.
Mike Rowe would laugh at every last one of them.
Second, a kid does not need to learn Brand X of a particular sort of software. They need to learn concepts, not specific implementations. So they should learn what a word processor is good for. Whether it's MS Word, or OpenOffice, or iWork (or pick some other word processor). Irrelevant. Learn what a word processor does. (Repeat for presentation software, spreadsheet, etc) It will make them more versatile in the real world. Additionally, the second option in there is free, thus solves the original problem of "we can't afford the licesnes". I have no idea what they need Creative Suite for. That's an even bigger sledgehammer than MS Office for putting in finishing nails.
Yet another advantage for OpenOffice, since it is free, the kid can easily take a copy home and use it for homework there too, and not inflict a large licensing cost on the family too.
My observations: There are some very good Indian developers. There are some very cheap Indian developers. My observations do not include any overlap between the two.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
They are missing a fairly dirty job in IT... Help Desk / Service Desk / Catch All Desk / fix it its not working desk..... Spend a year here and see what you think of your sanity and cleanliness after. Most of these people wouldn't know about network problems or pr0n infesting spyware unless the Help Desk dealt with it first.
"i lost my dignity on a slippery wiener"
The dirty part? Techies often play a little fast and loose with the truth. But it's the marketing hag who catches hell for it.
TFA goes on to berate techies for claiming something is ready when it isn't, etc. I don't buy it. Most techies I know are too truthful for their own good, partly because of the b/w nature of our world, and partly as an allergic reaction from cleaning up too many overpromise/underdeliver SNAFUs we inherit from Sales and Marketing types. I've been on the techie end of that equation too many times, and although you can take my unconfirmed anecdotal data as you wish, my guess is that most here have had similar experiences.
...
...
... [notices the MH's eyes glazed over] Okay, say something like this - "OLC 1.0 leverages Web 2.0 technology to bring the power of cloud computing to your fingertips."
...
...
... thanks! Bye!
Hypothetical conversation between techie and marketing hag:
MH: So, I'm like, trying to put together a press release and a flyer about OurLatestCoolthing1.0, and I was hoping you could like, help me with the technical parts.
T: Yeah, sure. Happy to help.
MH: Oh cool. So, like I talked to your manager, and he said that OLC v1.0 is fully Web 2.0 and cloud compliant, and is guaranteed to save companies 50% of their IT budget. Then he
T: What? No. That's just wrong. Are you sure he said that?
MH: [puzzled look] Yeah. I like just got done talking with him, and he said to talk to you, because you could like explain it better.
T: Oh. [mental note to speak to the boss man] Yeah, well you probably don't want to say "Web 2.0 and cloud compliant", because that doesn't make sense. There is no "Web 2.0" or "cloud" standard per se, and so there's really nothing to be compliant with
MH: [scribbling furiously] Wait, what? Standard? What do you mean?
T: There is no "cloud computing" standard. It's just a buzzword. You can't be compliant with it because
MH: [eyes light up] Oh! Good! I could use that! [scribbles] Okay, "OLC 1.0 leverages Web 2.0 technology to bring the power of cloud computing to your fingertips.
T: You probably don't want to guarantee any specific level of savings, either. Have you talked to Sales about that?
MH: Okay. Great, thanks! [leaves cubicle, then sticks head back in for one more question] Oh, by the way, how many engineers do we have certified on this?
T: Right now? No one. We just finished building the platform, and we haven't finished writing the training material yet. Why?
MH: Oh. How many will you have trained by like the end of next week?
T: Uhh, none. Not until the training material is finished. Talk to the technical writers and trainers.
MH: [worried] But like, how many will you eventually have trained?
T: [shrugs] Well, all the inbound tech support guys, for starters, and then
MH: Oh! Right! Good! So like, how many of them are there?
T: Eight guys at the moment, but
MH: Great
Half an hour later, the phone rings. A sales guys calls up to ask about the OLC v1.0. He just saw the latest marketing press release, and is really glad to see that it is "Web 2.0 and Cloud compliant".
I prefer rogues to imbeciles because they sometimes take a rest.
We went through this just a few months ago, as a tiny coder shop. We needed an Asterisk IVR built, had never done it before and didn't have time to learn, so we contracted out to an offshore company who were supposedly experts with Asterisk, as referred to us by a business acquaintance. We actually ended up with a working product, but it took so much hand-holding and error checking that by the time they delivered the final version, I knew more about Asterisk than they did, mostly because I read the PHPAGI docs a bit more thoroughly. And it was about 6 weeks late on a 2 week timeline. Face, meet egg.
The 10-hour timezone shift was a massive PITA. The communication hurdles led to poor quality output, because instead of asking us proper questions, they'd "play dumb" and do it wrong, seemingly on purpose hoping we wouldn't notice I guess. Every time they'd jiggle some code, we had to retest our entire flowchart and bark at them for every failure. Maybe I'm a hopeless idealist, but I like to think of contractors as a black box: work order goes in, completed work comes out. In my mind, that includes testing, especially since we had crystal clear pass/fail scenarios.
I'm sure there are some Indian shops that are worth the money (bell curve), but this one clearly wasn't. Sure, they were cheap, but I ended up doing more work to support them than had I done it all from scratch, so it ended up costing more. On the upside, I am now modestly self-sufficient in writing PHP scripts to drive Asterisk; another random skill I never wanted in the first place.
-Billco, Fnarg.com