Forgot your password?
typodupeerror
Businesses IT

What Do You Do When Your Mind-Numbing IT Job Should Be Automated? 228

Posted by samzenpus
from the with-my-eyes-closed dept.
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.
This discussion has been archived. No new comments can be posted.

What Do You Do When Your Mind-Numbing IT Job Should Be Automated?

Comments Filter:
  • QUIT (Score:5, Insightful)

    by Anonymous Coward on Friday August 08, 2014 @05:37AM (#47628821)

    QUIT

  • Automate it (Score:5, Insightful)

    by Lennie (16154) on Friday August 08, 2014 @05:37AM (#47628823) Homepage

    Learn how best to automate that task so you can start on other projects to automating other tasks.

    • by Anonymous Coward on Friday August 08, 2014 @06:00AM (#47628901)

      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.

      • by Anonymous Coward on Friday August 08, 2014 @06:59AM (#47629103)

        Please mod parent up! There are some decent points in this posting, regardless of it coming from an AC.

        I've spent a good 15+ years doing process automation. And process automation itself is indeed a process. It's significantly more than some server monkey slapping together a script together during lunch to do something. Don't get me wrong; such an approach is fine if it's going to sit on an admin's machine and be used every once in a while. But once enshrined in day-to-day operations, the game changes.

        What are the specifics that the script is going to do?
        What is the "Happy Path" operation of the script?
        How will common / uncommon errors / exceptions be handled?
        How will the script handle unknown or unexpected errors (ie. is it written to be resiliant)?
        How will the script be monitoried (e.g. snmp stuff) to ensure it hasn't choked?
        Where are these scripts being maintained and managed (ie, groupings of P.A. scripts in version control)
        WHERE IS THE DOCUMENTATION ABOUT THE SCRIPT?

        Stuff like that.

        Do some planning. Be a software developer about it. Just because it's a [Perl | Python | Groovy | Bash | DOS ] script does not mean it should be treated differently than compiled source or a more complex app.

        Do you need to turn this into a full-blown project, with 8x the overhead of just writing the damn script and sticking it in place? No.
        Do you just write the damn script and hope for the best? No, not if you want the system to die a horrible, disfiguring death.

        So, put a bit of planning into what's being done. Prove the script out first. Test it (remember that?). Manage it.

        • by Sobrique (543255)
          Scripts are generally more accessible, but that's about it when it comes to comparison with other languages. That means you get some pretty bad scripts, but ... well, there's no real reason to not use decent coding practice. The core one being 'get everyone involved a working knowledge of the language'.
        • by landoltjp (676315)

          Sorry, I had posted the above, but clicked "Post Anonymously". Didn't want to leave the impression that I was the Posting AND Replying message

      • by Anonymous Coward on Friday August 08, 2014 @07:00AM (#47629107)

        That is what documentation is for.

        Not just user documentation, but also system documentation. Good commenting of the procedure can also help.

        Without the documentation you can't pass on the procedure (or support).

        Now, even without documentation, it becomes just your baby... Maybe it helps you do your job, but you better have SOME documentation so you will know what it does, and how to change it when you HAVE to change it in the future.

        • Unfortunately documentation is the epitome of "in a perfect world, yeah, but we have another problem to tackle right now."

        • This is an example of where DevOps [wikipedia.org] comes in handy. Developers make requests, and devops creates it (it it doesn't already exist), a maintains it.
      • 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.

        Which is a social and cultural problem, not a problem of automation itself. If people were using open environments similar to Smalltalk or Oberon, half of those problems would go away. As ESR put it in TAoUP, there are simply systems hostile to casual programming. Now he of course draws the comparison between IBM's MVS and Microsoft Windows on one side, and Unix on the other side, but I'd actually stack MVS and Windows AND Unix against Smalltalk and Oberon. (Mind you, those two systems are far from being pe

        • by mysidia (191772)

          Which is a social and cultural problem, not a problem of automation itself. If people were using open environments similar to Smalltalk or Oberon half of those problems would go away.

          Switching to a new language won't solve the problem. Documentation is the right answer, but not just any documentation will do.

          You need to understand how the manual part works before you think of having an automatic part.

          Then you need a document for the automated version of the process: hyperlinked to a document about ea

          • I wasn't talking about languages, more about environments (both that I mentioned are not merely a syntactic and semantic definitions of a language, they're complete software artifacts, with OS kernels, runtimes, compilers, tools, and conventions). And actually, this is the part I actually had in mind: the documentation tools suck. These days, I'd expect some sort of an inter-linked system, allowing you to not just jump between pieces of code in your editor, but, i.e., to find all relevant document referring
        • Why are you stacking operating systems against languages? Both Smalltalk and Oberon are available for MS Windows and Unix, if not MVS.

          : Also, what are the advantages of Smalltalk and Oberon over, say, Perl or Python, to counter the fact that it's easier to find Perl and Python people when something breaks? Carrying their own OSes along so they're harder to integrate into another environment? All you need in this case is good documentation and readable programs, and it's just as easy to do those in Perl

      • by Sobrique (543255)
        Not that you'll care, if you're the person who's already moved on :).
      • by Anonymous Coward on Friday August 08, 2014 @07:34AM (#47629259)

        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.

        Oh, enough weasel words. You start off with a strawman of "it saves a few minutes a day" when in fact nobody automates systems that actually only take a few minutes a day - and it's probably your "few minutes a day" that's off, if they do (you're ignoring the costs of errors - the few minutes a day can often cost half a day if it's done wrong). Then you quote "documentation" as if it's some kind of mythical being and again maybe in your experience it is, but get real. Documentation solves all the problems you cite. Documenting your automated systems does reduce the actual cost of maintaining them. And I suspect if you'd ever seen it in place and actually working, you wouldn't be giving us this luddite anti-automation rant on the basis of a woeful misunderstanding of what constitutes a business case.

      • by joh (27088) on Friday August 08, 2014 @07:45AM (#47629305)

        As so often XKCD says this much shorter:

        http://xkcd.com/1319/ [xkcd.com]

      • Clearly progress is a bad thing. F*** science and technology. Who needs them?
      • But that's usually the easiest part of the whole process. They rarely look beyond it, to the maintenance phase.

        We'll just automate the maintenance phase.

      • So do some real analysis...

        I took two quarters of real analysis as an undergraduate, but I never took complex analysis.

      • I feel your pain, but the area I work with in the company has been using trello to keep track of this kind of stuff, we have one card for each process/application/script running on our servers. These cards describe what each script does, where it runs, how often it runs and so on. It has been working great.

      • by mpe (36238)
        I always hear managers and programmers say, "We'll just automate it!"

        The word "just" can cover a multitude of sins.
      • by Wycliffe (116160)

        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!

        If it's only saving a few minutes per day then when/if it breaks then you scrap it. Why would you spend "days, weeks, or even months" fixing a script
        that is only saving you a few minutes per day?

        This xkcd comic tells you when to automate: http://xkcd.com/1205/ [xkcd.com] but it applies equally to how long you can afford to spend fixing a script that breaks.
        This is across 5 years so IMHO you should probably cut the number in half so that 1) you are actually coming out ahead and 2) you have some room
        for updating/rep

      • by Hadlock (143607)

        You need a job scheduler to centralize the tasks and knowledge of the processes, so you can bring someone in to run all the automated tasks. Sure you still have a human in the equasion, but now you're down to 1 person, instead of a room of 20.

    • by AmiMoJo (196126) * <mojo@NOspAm.world3.net> on Friday August 08, 2014 @06:05AM (#47628919) Homepage

      Learn how best to automate that task so you can browse Slashdot all day.

      FTFY.

    • Re:Automate it (Score:5, Insightful)

      by Lumpy (12016) on Friday August 08, 2014 @06:51AM (#47629069) Homepage

      Absolutely, but DO NOT TELL ANYONE. honestly automation will not get you a raise or a promotion, it will just get you extra work. for the same pay.
      Automate all of it and keep your frigging mouth shut.
      Hell I used to automate emails to be sent at 2am so that management though I was working 24/7.

      • Re:Automate it (Score:5, Insightful)

        by Sobrique (543255) on Friday August 08, 2014 @07:19AM (#47629181) Homepage
        If you pull out the all the stops occasionally, you're a hero. If you do it routinely, you're taken for granted. It's hard enough to measure 'productivity' in IT anyway. Far better to automate your job, and 'pay yourself' to support it on an ongoing basis.
      • Re:Automate it (Score:5, Insightful)

        by Corbets (169101) on Friday August 08, 2014 @07:29AM (#47629237) Homepage

        Absolutely, but DO NOT TELL ANYONE. honestly automation will not get you a raise or a promotion, it will just get you extra work. for the same pay.
        Automate all of it and keep your frigging mouth shut.
        Hell I used to automate emails to be sent at 2am so that management though I was working 24/7.

        If you've automated your job, *shouldn't* you get new tasks to do? You're being paid to do the job to the best of your ability. You've done that by automating - but that leaves you on-the-clock time to do other productive tasks.

        • Re:Automate it (Score:5, Insightful)

          by plopez (54068) on Friday August 08, 2014 @07:51AM (#47629335) Journal

          No. That would be wrong. A worker should maximize efficiency by discovering the best way to achieve maximum pay with minimal work. That is what economists say the company should be doing and since companies are now people and workers are people that's what workers should do. In fact doing it any other way flies in the face of the "Free Market" and therefore maximizing efficiency is both an ethical and moral imperative.

          • Re:Automate it (Score:5, Insightful)

            by mrchaotica (681592) * on Friday August 08, 2014 @08:50AM (#47629723)

            Well, it would be okay for you to get additional tasks to do as long as the pay increased in proportion (which of course, would not actually happen). So the GP was not necessarily wrong, just unrealistic.

          • by Wycliffe (116160)

            No. That would be wrong. A worker should maximize efficiency by discovering the best way to achieve maximum pay with minimal work. That is what economists say the company should be doing and since companies are now people and workers are people that's what workers should do. In fact doing it any other way flies in the face of the "Free Market" and therefore maximizing efficiency is both an ethical and moral imperative.

            This "free market" theory of yours works for a while until someone else discovers that they can automate the task
            you've already automated and you're out of a job. That's how the "free market" really works. If you were the only
            farmer with a combine then you would make a ton of money but eventually everyone else gets one too and your
            competitive advantage goes away. If you really do come up with a "time-saving" device, the best way to get rich
            with it is to either hide it so noone knows about it or license i

          • by operagost (62405)
            As a dirty libertarian capitalist, I agree with this. Management's job is to set objectives and make sure they're accomplished, within budget. If one of their employees can meet these objectives in 20 hours a week by being a genius with the computing speed of Data and the communication skills of Ronald Reagan, so be it. If they can meet them by being cunning, and working a few extra hours to automate tasks so that they can meet the objectives in 20 hours a week, so be it. Only a moronic manager (but I r
            • Re:Automate it (Score:4, Interesting)

              by digsbo (1292334) on Friday August 08, 2014 @10:52AM (#47630553)
              And, if the worker wants to, he should ask for a raise and more work. This would benefit him and the business financially; whether it would happen depends on the wisdom of his managers. Less efficient firms would be forced to innovate in kind or suffer competitive disadvantages.
          • by plopez (54068) on Friday August 08, 2014 @11:42AM (#47631069) Journal

            Good Lord. Next time I will explicitly set the 'sarcasm' tags. There are too many things wrong with my argument to even begin to suspend disbelief.

        • Re:Automate it (Score:4, Insightful)

          by pla (258480) on Friday August 08, 2014 @08:27AM (#47629547) Journal
          If you've automated your job, *shouldn't* you get new tasks to do? You're being paid to do the job to the best of your ability. You've done that by automating - but that leaves you on-the-clock time to do other productive tasks.

          If they want to pay me hourly, then yes, absolutely. As long as employers do their damnedest to push the limits of "exempt", however, then very much no. I get paid to perform certain tasks to the best of my ability. As long as my employer doesn't care whether that takes me 40 or 60 hours a week, then I don't care if it only takes me 20.

          Note that I mean this somewhat in the abstract, in the sense that I refuse to work for someone who expects me to work more than 40 a week regulary. My current employer actually treats me pretty well, and as a result, yes, if I automate task X, I'll spend my newly-found time doing the rest of my work somewhat better (I wouldn't specifically say "picking up new tasks", because we all know that what we can do in 40 hours doesn't mean we should to produce the optimal result).
        • by MarkvW (1037596)

          Yes, you have a moral duty to your corporate overlord to serve it to the best of your ability. You must strive to do more than the job that you are paid to do because that is your moral duty. In return, you can fully expect your corporate overlord to honor its moral duty to you (because it has no duty to you).

        • by roc97007 (608802)

          Absolutely, but DO NOT TELL ANYONE. honestly automation will not get you a raise or a promotion, it will just get you extra work. for the same pay.
          Automate all of it and keep your frigging mouth shut.
          Hell I used to automate emails to be sent at 2am so that management though I was working 24/7.

          If you've automated your job, *shouldn't* you get new tasks to do? You're being paid to do the job to the best of your ability. You've done that by automating - but that leaves you on-the-clock time to do other productive tasks.

          Perhaps, but with the understanding that part of your time will now be devoted to maintaining the automation you created.

      • by ALeader71 (687693)

        Wow, sounds like you've been burned! Honestly, in our industry why wouldn't you automate the drudgery, then move on to other tasks? Or perhaps use the experience to seek a better job?

      • by sjbe (173966)

        Absolutely, but DO NOT TELL ANYONE. honestly automation will not get you a raise or a promotion, it will just get you extra work. for the same pay.

        And if you worked for me and I found you doing this I would fire you on the spot. You are being paid to perform a certain number of hours of work, not to sit on your ass and collect a paycheck. What you are suggesting is fraud, plain and simple.

        • And if you worked for me and I found you doing this I would fire you on the spot.

          "Whereas..."? "...if you tell me..."? "...I'd give you..."?

          Huh, nothing, weird. It appears you think only of negative reinforcement. So if your employees double their productivity, you offer them no reward, only threats if they seek a reward.

          This leaves them with three choices:

          A) Automate a process, tell you. You increase their workload to compensate. Result: Same pay, same workload, plus responsibility for the automation process.
          B) Automate a process, don't tell you. Result: Same pay, decreased workload, s

        • Actually, nobody's watching my hours, although I put in about 40 a week (it varies). I get evaluated based on the work I do. As long as I get enough stuff done with good quality, everybody's happy and I get a good annual review and pay increase to match.

    • Re:Automate it (Score:4, Interesting)

      by jafiwam (310805) on Friday August 08, 2014 @07:01AM (#47629109) Homepage Journal

      Learn how best to automate that task so you can start on other projects to automating other tasks.

      Yup. But do it in secret and don't share the automation with the employer. Use your spare time to look for a new job.

      IF you come to the point where know your job is going to evaporate, it's better not to make a lot of waves (and that includes positive ones) until you are ready to go anyway. Your employer is already NOT paying attention and may not have a full understanding of what you do already. You'll be facing "the Bob's" in no time.

      There is a reason they call it "work." Boring and repetitive comes with that. Brush up on your Zen skills and deal with it. And FIND ANOTHER JOB.

    • Relevant XKCD http://xkcd.com/1205/ [xkcd.com]

      We actually use that chart to represent time gain efficiencies to automation.

  • Automate them (Score:5, Interesting)

    by Errol backfiring (1280012) on Friday August 08, 2014 @05:44AM (#47628855) Journal
    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.
    • Re:Automate them (Score:5, Insightful)

      by RabidReindeer (2625839) on Friday August 08, 2014 @06:35AM (#47629027)

      I always automate.

      Then I get laid off because "I'm not doing anything."

      People who don't automate, and get paid by the hour to do the same thing over and over again stay on.

      • by Lumpy (12016)

        Your fault for opening your mouth and telling them.

      • by Sobrique (543255)
        Lots of people 'play spreadsheets' all day, which is working really inefficiently. Some companies prefer this, because they operate on billable hours in the first place. You being efficient costs them money. Some companies know better, and will value your skills. You should go and work for those. Getting laid off sucks a bit, but it's far from the worst thing that'll ever happen to you.
        • by Nukenbar (215420)

          As an attorney, I totally understand this.

          Considering most of our job is writing, I'm amazed at how poorly most people understand Microsoft word. I am not an expert, but if you don't even know what style sheets are or how to insert a cross reference, you are creating SO much more work for yourself as you try to "clean-up" the document later.

          But as attorneys who are getting paid by the hour, there can be short term benefit (more billable hours) to this inefficiency.

    • by landoltjp (676315)

      "Actively lazy" is a GREAT way to approach automation. Good job. My colleagues and I call that "Precrastination"!

      • by Sobrique (543255)
        I've espoused the doctrine of proactive laziness since I started sysadminnning. I figure I'm doing my very best work when there's nothing that I need to be doing, and I can be spending my time fiddling with the next thing.
        That means applying appropriate automation and scripting. (Don't overdo it - not all scripts need to be gold plated).
        Decent documentation. (Which is easier: explaining or fixing a problem, or saying 'RTFM' and waving a hand dismissively - if TFM is up to scratch, they won't come back a
  • Sorry but this is what I do for a living. Find an automation tool that works and implement it. Rinse and repeat!
    • Automating simple/repetitive tasks represents most of my self assigned projects (in between larger/outside funded development projects which are assigned) the most important thing is to always be working on something... or at the very least always appear to be working on something.
  • by oodaloop (1229816) on Friday August 08, 2014 @06:03AM (#47628911)
    Homer once automated his job with a plastic dipping bird, with disastrous results.
    • by omnichad (1198475)

      I didn't forget. He tripled productivity! I was going to post a reference myself, but I decided to crowdsource it. Does that count as automation?

  • My goal is to replace myself with a little shell-script.

    • You're going to be replaced by a guy who can replace your job with a Python / Ruby script ^^ ;p

      • by Sobrique (543255)
        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.
  • So any net savings (Score:5, Insightful)

    by Kjella (173770) on Friday August 08, 2014 @06:08AM (#47628929) Homepage

    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 [xkcd.com]
    Is it worth the time? [xkcd.com]

    • by omnichad (1198475)

      But even doing the maintenance and eating up the savings is fine if it doesn't come out taking longer overall. You spent the same amount of time working, but didn't have to do anything dull or repetitive.

    • by chispito (1870390)
      The "Is it worth the time?" comic is illustrative, but I think it's built on false premise. I don't automate parts of my job (just) to save time, I do it because repetitive tasks, that I know can and should be automated, drive me insane. Even if there is no net time savings, I'd rather take the creative route.
  • by Stolpskott (2422670) on Friday August 08, 2014 @06:20AM (#47628979)

    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.

    • It's 5 Ws of trouble shooting... you forgot Who.

      You are right a lot of jobs just plain cannot be automated away but I bet if you ask any seasoned sys admin they will show you a boat load of scripts that they run and watch while drinking their {insert caffeinated beverage} and reading /.

      I have gigs of scripts I've collected over the years that do all kinds of creating/disabling/moving/modifying AD accounts and custom reporting for ldap and various applications, even telephony related scripts. {gedi master?}

  • Automate it (Score:5, Insightful)

    by msobkow (48369) on Friday August 08, 2014 @06:36AM (#47629029) Homepage Journal

    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'd tend to agree with you, although the problem here is often not the employee and his/her laziness or incompetence. The fear often comes from uncertainty that management recognizes the value in what you've done for them.

      For example, I had a buddy who used to work for a company that installed and maintained point of sale systems. He found all sorts of time consuming processes that he could automate, by virtue of knowing how to code in languages like PHP or Perl, and did so wherever possible.

      The problem is,

  • by Idimmu Xul (204345) on Friday August 08, 2014 @06:53AM (#47629079) Homepage Journal

    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..

    • by mikael (484)

      You are doing bug tracking by hand??? We used to that back in the 1990's. I was given a three day task to sort, reorder, prioirtize about 200 open tickets in a single text file. Wrote a script in six hours to do this automatically, and had the report completed in minutes. Today, we would just use bug-tracking software like Jira

      https://www.atlassian.com/soft... [atlassian.com]

  • by anmre (2956771) on Friday August 08, 2014 @07:45AM (#47629303)

    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 [imgur.com] which sums up your situation perfectly!

    Also, smile often! :)

  • After reading a few responses I thought I'd share my observations on workers, and the "Three Kinds of Lazy:"

    The Plugger: Doesn't like the drudgery, but rationalizes it with victimization and anxiety.
    The Troll: Doesn't like the drudgery, does a barely passable job. Jellously guards all knowledge of how to do said task under the idiotic assumption that this will make them indispensable and thus impossible to eliminate.
    The Neckbeard: Hates drudgery. Will spend enormous amounts of time learning whatever s

  • get unionized before you are Automated out of work!

  • What, people thought the open source movement of the 2000s was due to some sort of hippy movement?

    No, it was due to IT departments becoming redundant and the engineers spending that time very effectively.

    That wave has crested.

  • Automate it, don't tell anyone, and then get paid for doing nothing while you waste all of your time browsing stuff on the Interweb. That's what I've done...
  • Just because you automate it, doesn't mean you have to tell anyone.

    Be a shame, you know, if those scripts stopped working..

    • by sylvandb (308927)

      This.

      Then as you monitor the automation you improve the scripts and your active involvement lessens over time, leaving more time for other things.

      Maybe automate other parts of your job?

      Self-improvement (training, education, experimentation, etc)?

      Being available to consult or assist others, improving your "team player" metric?

      Sell your ideas for automation, demonstrate the prototype (before it is perfected, of course)?

      Entertainment? (Anything so long as it doesn't get you fired, which in a good company shou

  • I've been in IT for over 30 years and I've seen a lot of changes. My first program was coded onto punch cards and read into the system that way. Nowadays I'm doing some traditional programming and SQL, but also working with some new tools like SAP's Data Services and Dell's Boomi. These newer platforms are very visual in how you hook up your components, yet still offer the flexibility to write special modules in languages like Java or ABAP. This, I think, is the future of programming, where a lot of the

  • by praxis (19962)

    Automate it while using emotional intelligence to find a more satisfying role in your or another company (which might be your own business).

  • Automate what you can, but even with automation in place, someone who understands what's being automated and how automation works still needs to be around to monitor and improve the system. Automation should only ever replace tasks with are safe and repetitive, to free up time for people, such as IT staff, or engineers, to focus on much more important tasks.

    The way I would spin it to a boss ( and have before ), is this way: "I made a spread sheet and pie chart outlining where my time is spent each wee
  • There will always be something in my experience. I do it all the time, though not part of my primary job description. It is usually because of some wonky legacy system still in production that has been terribly maintained because the organization doesn't have the money to fix properly, and certainly doesn't have the money to replace it. Usually patches are applied, which despite UAT ends up breaking some other unforeseen part of the application because it was apparently originally designed by blind monkeys

  • I've done this many times.

    In one instance it wasn't my task, but the task of 2 employees that I was supervising. My boss had given them a task that took each of them 8 hours to complete (turning phone logs into readable reports, daily). One would start the process and hand her work off to the other which was then turned into management at the end of the second shift. Each day, processing the logs from the previous day. At best, the report data was 24 hours old - often indicating trends after it was too

A language that doesn't have everything is actually easier to program in than some that do. -- Dennis M. Ritchie

Working...