[mercer]

I realized exactly this when I wanted to write a backup script for some of my client's websites.

My usual process had been to 'manually' backup using rsync, which was a matter of cutting and pasting the commands from a text document.

When automating, however, I realized I'd also have to check if certain files (db dumps) were present, and of course if the script itself succeeded.

I then realized that in this particular case, the simple cut and paste approach was perfectly fine, because: 1) it would take months for the time spent automating to be worth it compared to a quick cut and paste, and 2) it was much safer for me to quickly scroll back in my terminal and see if the particular files were present.

Now I wouldn't generally recommend my approach, but in context it made sense not to automate, and yet I felt a 'need' to automate anyways.

[icebraining]

Automating is not just about speeding up the process; it's also a way of lowering the bus factor[1] of the process. What happens when you go on vacations, or you get sick? Do the websites stop being backed up?

Besides, you should always document your process, and writing a backup script doesn't really take much more time than a detailed description in English.

[1] https://en.wikipedia.org/wiki/Bus_factor

[arthurjj]

Exactly, writing down the steps should be the first step in automating a process. The order I do the steps are:

1. Write down the directions to do the task 2. Have someone else follow your directions. Any time you need to interrupt them because you missed something add a note or additional step 3. See if any part (or the whole thing) is worth automating