Horne's job is to evaluate and edit dozens of reader contributions each day, then choose which ones to publish. He quickly discovered that major contributors were spending most of their time hawking products, while others were using multiple identities in order to argue with themselves. For two hours a day, Horne attempts to douse flame wars fueled by a combustible mix of arrogance and ignorance, snuff out personal attacks, and deal with threatening emails complaining about his own performance -- all for free.
The dirtiest part of the job? Dealing with oversize egos seven days a week.
"The hardest part isn't the mechanics of editing, it's the politics of dealing with people's opinions," he says. "I can't escape the feeling that some Internauts hang around Usenet just because they've found out that it's a safe place to act like a jerk. If they said some of these things at home they'd be divorced in a month, and if they held forth at work with these poorly thought-out, knee-jerk reactions they'd be fired in a minute."
Dirty IT job No. 5: Orphaned code debuggerProgramming is challenging work. Working on another developer's code adds yet one more level of complexity. But cleaning up after someone else's programming mess with nothing other than their badly written code as your guide? That's when things get really dirty.
Joe Emison is vice president of research and development for BuildFax, which maintains contruction records for more than 70 million U.S. buildings. But seven years ago he did some freelance programmer work for a pair of Web developers who insisted on using ClickCartPro, a shopping cart app written in Perl.
ClickCartPro was a wet hot mess, says Emison. Among its flaws, the code had no indentation, no comments, and no documentation, which means he had to hunt for subroutines and guess at what the original coders had in mind. It used only global variables, so changing the values in one place changed it everywhere else that variable appeared. It made extensive use of eval(), which hides error messages from end-users but also from developers, making it nearly impossible to locate the source of a failure. And the code was more than 100,000 lines long.
"I had to go line by line in a text editor trying to figure out where things failed and why," he says. "I kept saying to the developers, 'This program is crap; stop using it.' But they had invested a lot of time in customizing it, and they had a lot of legacy customers who were unwilling to pay for a new cart."
Emison says this kind of dirty job is something many programmers encounter, especially when dealing with Web code written at the turn of the last century. Still, it could be worse.
Sign up for Computerworld eNewsletters.