By the number of people that are pissed off about webdev and still don't success at changing it, and by the amount of "Oh Brand New Automagic Solution for Everything (TM)" coming up every month and still failing at fixing the mess that webdev is... I'd say it's not so easy to "fucking change that".
I don't know if it's easy or hard. I'd bet it's rather on the easy side. What I know is that it's not with having dealines to produce the next product that anybody will have the time to take some step back and come with a better (more automatic) way of doing things.
What's painful, it's not doing something repeatitive. It's being presured to repeat it, without being let automatizing it, which is what we should do as programmers.
I had a colleague once that wanted to invest 4-8 hours writing a script that would save her about 1 hour each time it is run. The script was expected to be ran about once a week.
She did the wrong thing and asked her boss. "Not enough time, there's more urgent things to do."
She then lost an hour per week, contributing to the general sense of urgency that she lived under. Of course, this wasn't the only such script she thought about by far.
-----
My advice: if you can shoulder the risk, automate it before your boss tells you not to.
I look at it this way. Bosses don't understand craft, only results. It's your job to understand the craft, and to get the results your boss is looking for. Automation, scripting, refactoring, these things are part of the craft and can't be skipped, so they're part of the job and it's not done until they're done.
So don't present your results to the boss until all the work's done. It takes as long as it takes.
frankly, it sounds like she could have simply taken the initiative and wrote the script on her own time. seems like she could have simply done it over a weekend, and it would have been worth it if she truly felt that it would save her an hour per week.
That might be true - but she should do it only to prove that those kind of investments are worth it, and to gain trust from her boss/team.
I think programmers should be paid to not only do the crappy grunt-work, but also for automating it away, even though there will sometimes be cases where it turned out not to be worth it. To me, the automating is part of the job.
And sure, I remember when I used to think I could rewrite entire applications in a few hours the "right way", but that was pure inexperience on my part. For a junior dev, they might want to run it by someone more experienced, but otherwise, these kind of tangents can turn out to be some of the most valuable time spent on a project.
