Something I find amusing is that the ability the author demonstrates here, to notice that a task is repetitive and has a programmatic solution, is itself a skill that has to be learned, and one that's different than programming.
Once, when I was working on a group project in an operating systems class, we modified our kernel malloc and free routines to print the relevant address every time they were called, to do some simple leak-checking. The result was a file of a few thousand lines like "malloc 0x94583900", "free 0x34739A4", etc. One of my partners looked at the file and said some variant of "oh no - this is going to take hours to match up". Apparently it hadn't occurred to him, someone who'd been programming professionally for years and who only minutes before had been tweaking the internals of a process management function in a multithreaded x86 operating system, that there was an easier avenue available to him.
I have a darn similar story, writing a virtual memory manager for OS design class. I was the only one in class who even thought of instrumenting the thing, and then wrote a Python program to read the traces and tell me when frames got swapped to or from the wrong disk pages.
I was also the first one in class to actually finish the project.
There is another side to it when a programmer looks for a technical solution unnecessary (when all you have is a hammer -- everything looks like a nail)
But I'd add that even tasks that only require a quick-and-dirty solution can frequently benefit from quick-and-dirty automation. A few throw-away lines in an interpreter environment like irb, for example can often shave several minutes of certain tasks, and throwing a lit bit of code into such tasks can certainly make some otherwise dull processes more interesting.
Once, when I was working on a group project in an operating systems class, we modified our kernel malloc and free routines to print the relevant address every time they were called, to do some simple leak-checking. The result was a file of a few thousand lines like "malloc 0x94583900", "free 0x34739A4", etc. One of my partners looked at the file and said some variant of "oh no - this is going to take hours to match up". Apparently it hadn't occurred to him, someone who'd been programming professionally for years and who only minutes before had been tweaking the internals of a process management function in a multithreaded x86 operating system, that there was an easier avenue available to him.