Slashdot Mirror
What Do You Do When Your Mind-Numbing IT Job Should Be Automated?
jfruh writes Not everyone has a job like Homer Simpson, who's been replaced at various times by a brick tied to a lever and a chicken named Queenie. But many IT workers have come up against mind-numbing, repetitive tasks that probably could be automated. So: what do you do about it? Well, the answer depends on how much power you have in an organization and how much your bosses respect your opinion.
QUIT
Learn how best to automate that task so you can start on other projects to automating other tasks.
New things are always on the horizon
Well, automate them, off course. That is how I started my programming career. I started as a technical draftsman using AutoCAD, and I was "actively lazy": when I had to type something 10 times, I wrote a little program to do that for me. When my bosses noticed that my computer was better configured than that of my colleagues, I started getting programming assignments as well.
Nae king! Nae laird! Nae yurrupiean pressedent! We willna be fooled again!
I always hear managers and programmers say, "We'll just automate it!"
But that's usually the easiest part of the whole process. They rarely look beyond it, to the maintenance phase.
The maintenance phase, of course, often lasts far longer than the implementation phase. It often outlasts the people who pushed for the automation in the first place, and the people who initially implemented it.
No automation is perfect, and no surrounding environment is static. Things will break, or change will eventually be needed. And this is where automation can often fall flat on its face.
I can't count the number of times I've seen companies with scripts or apps that perform some simple operation, but it only saves a few minutes each day. Yet at some point something with the automation breaks or needs to be changed, but the original developers are long gone, and now some other developer has to investigate.
This poor developer will end up needing hours, days, weeks, or even months in some cases in order to find out where the fuck the script or app is running, where the hell the most recent version of the source code is, how to get it running on a development system, and how it works, all before being able to make the fix or the change. Then it takes time to fix it or make the change, plus some time for testing, and then it needs to be redeployed, and finally it needs to be monitored for some time.
So the automation saved maybe a few dollars a day. Yet just a single fix or change to the automation can end up costing hundreds, thousands, or even tens of thousands of dollars once all is said and done. Merely one small fix or change can literally wipe out any cost savings that the automation has ever brought in the past, and then wipe it out for the next few years!
It's all rainbows and roses to claim that "documentation" or "training" or "best practices" will solve these problems, but even when those are in place and actually working, they rarely reduce the actual cost of maintenance.
So do some real analysis before screaming, "JUST AUTOMATE IT!" The cost of even simple or minor automation can quite often far, far exceed the benefits it'll ever bring. Maybe it's better to have the intern or low-paid employee just do the work manually for a few minutes each day.
Homer once automated his job with a plastic dipping bird, with disastrous results.
Tic-Tac-Toe, Global Thermonuclear War, and relationships all have the same winning move.
I've ended up creating a few solutions where I think I'd rather spend three hours doing something creative than one hour doing it mindnumbingly dumb and repetitive. Often the maintenance of tweaking it eats up the savings.
Relevant XKCDs:
Automation
Is it worth the time?
Live today, because you never know what tomorrow brings
Most of the IT jobs (emphasis on the "jobs" part) that I see, cannot be automated - or if they can be automated, the automation needs a level of oversight and constant tweaking that it is not economically viable to automate the process.
Almost without exception, an IT "job" can be split into discrete "tasks", where some of the tasks can be and should be automated for various reasons, but in terms of the W.W.W.W.H. (What, Where, When, Why, How) aspects, the reason for automating (Why) has a significant bearing on whether it would be a good idea to even try automating.
Automating the tasks which can be automated within a job makes sense in many cases - relieving the employee of the trivial and repetitive tasks to tackle the more high-value elements of the job. From a commercial perspective, if you are spending most of your time on the high value tasks, you are probably earning more money for your company or providing better value. As long as the boss recognizes that fact, your job should be more secure and your pay packet should, at some point, see an increase to recognize the higher value that you represent. ok, you might need to leave the company and parlay that higher value experience at a new employer to see the increase in your salary, but if your CV can show a successful sequence of task automation leading to higher productivity, then you will probably be more in demand.
If you have either a role that can be automated to the point where you are irrelevant, or a manager who thinks that your role can be automated to the point where you are irrelevant, then my advice would be to start looking for a new job where either you are more stretched or your manager appreciates your contributions more.
Automate it and find something else to work on. At no place I've ever been has there been a shortage of work.
Only the lazy and incompetent fear automating themselves out of a job. If worst comes to worst, you'll end up maintaining all those scripts you created, fighting fires, and dealing with the "one off" situations that the scripts can't handle.
I do not fail; I succeed at finding out what does not work.
One of the tasks here is the daily generation and collation of statistics across our various platforms to present to the clients. It contains things like the state of the tickets, number of tickets raised/closed, peak data across the platforms, systems metrics for utilisation and other similar things.
Currently these metrics are gathered manually be people eyeing up graphs and manually reading the data from them or running scripts that pull out metrics they need, it went from a half hour task to a 120 minute task, daily, as we've been growing.
I created a scaleable system that polled all the required statistics, from all of the various different systems in place, directly accessing the RRD files that generate graphs, polling our ticketing systems API to access the data, etc etc and then pushed them in to a database which could be polled easily for historic data as well as interrogated via a front end to generate the reports. It even allowed you to alter text in the report and export it to PDF to email to the clients.
After 2 years it's still sat, waiting to be rolled out, because of politics. The guys that run the reports just work from a process document and aren't really good enough to do much else. With the additional free time they have it would be too transparent that they can't do anything other than follow process but we do need them for various other tasks that can't be automated. At least by doing the reports manually they look really useful and the clients are happy..
The problem with slashdot is that most of its users were bullied and stuffed into lockers as kids!
So do it in Perl - it'll be good enough to make your life easy, and inscrutable enough that anyone trying to 'automate you' will recoil in horror.
I've found myself in this exact situation.
If you have the desire and/or ability to use your computer properly and automate tasks, and your job title is "______ Assistant", your boss will likely not respect you enough to permit automating anything. Therefore, you should do it as quietly as possible, and do not expect any pats on the back for mysteriously having perfect reports in your boss's inbox every morning at 8:31AM, or data requests completed before he/she even has time to walk back to his/her desk. Your boss may "expect" perfection, but will not actually know what to do about a subordinate who is actually capable of delivering it.
Expect to have only Microsoft VBA at your disposal. And amuse yourself daily with this image which sums up your situation perfectly!
Also, smile often! :)
As so often XKCD says this much shorter:
http://xkcd.com/1319/