The Recursive Nature of Automation

by debianjoe

 

There is no better way to learn to do something manually than to write a way to automate it.

This has at least been a huge factor in my own experiences.  It’s probably one of the biggest reasons to take up writing scripts for daily maintenance, aside from simply making your own life easier.  By taking the time to write something that will “automagically” fill a need, you will probably find that you have a much better grasp on the core concept of what your project does.

Allow me to explain how this normally works for me.  I’ll decide that I could really benefit from a small tool to perform a series of operations.  Once I sit down and think about the entire process, I realize that I need to research out all of the possible options for each tool that I’m scripting for.  I’ll spend a few hours reading man pages in detail and playing with different command line arguments to see how passing variables to each of them is best performed.  After creating a skeleton form of the project, I’ll start looking into ways to make it better, harder to break, and to use less “spaghetti code”.  By doing this, I’ll normally figure out a few ways to cut corners and make the project cleaner.  By the time that I finish the project it will probably save me some time, but I’ll have also grasped a much deeper understanding of each operation that I’m performing.

Sed is one of the tools that I picked up using this method.  As I’ve mentioned before, my bash-scripting is mediocre at best.  I took some time to try to at least learn how to perform some basic operations with bash, and during this process I realized that I wanted to change how my output looked.  I read up on sed, and determined how to use the basic search-and-replace functions.  After getting it to work how I wanted in my scripts, I found myself replacing things that I would have once used my text-editor for with sed one-liners.  If I had a file where I wanted to replace a single variable in, I’d so it with sed.  I found after some use that it was generally faster than how I had previously performed the same operations.  I started to use it more and more, and thus went back and learned more about how sed worked.  Now, it’s not uncommon for me to use sed directly from the shell to perform an inline edit to a file.

I really cannot name all of the things that I’ve learned through the process of trying to not have to learn them.  My attempts at being lazy have often proven highly productive.  For this reason alone, I suggest trying to answer simple problems with automation.  While you may never write the greatest tool for the job, you will most certainly learn something useful in the process.