[​​White Belt] You can start automating tasks for yourself no matter what your role or how your project is structured. (Plus, it’s a given that newbies will be given some mundane tasks—exactly the kind of tasks that beg for automation.)

In any industry project, the program build is automated, so you just need to type make or click a button. The tools used for compiling source code, however, are generic automation tools; they can be used for a lot more than running compilers. Like many of the topics we’ve discussed, automation is a productivity multiplier—use it well, and the time invested up front multiplies your effort later.

There’s a famous Despair.com de-motivational poster that says, “If a pretty poster and a cute saying are all it takes to motivate you, you probably have a very easy job. The kind robots will be doing soon.^[28]” If a robot can do the job you’re doing, then either you should make the robot or someone else will. Your value as a programmer is in your thinking, not your typing.

Automatic and Repeatable

The goal of automation is twofold: to eliminate tedium and to give you repeatable results. On the tedium side, there are a lot of steps in a programmer’s workflow that look like this:

1. When someone changes a file in the version control system (see Tip 13, ​Control Time (and Timelines) ​), then the installer package needs to be rebuilt.

2. When the package changes, it should be deployed to the test servers.

3. When a test server gets a new package, it should kill the running application process and start the one in the new package.

4. ...and so on.

How many times do you need to run these commands by hand before you want to pull your hair out? As it turns out, computers are great at these kinds of tasks. You can use hooks in your source control system to trigger the package build. Deploying the package should be as simple as copying it to a network repository and telling the repository to update itself. Restarting the application on each server could be a step in the package’s post-install process.

Any time one action naturally follows another, you have an opportunity for automation. Use your thinking to spare yourself the typing.

Automation Reduces Error

Automation isn’t just about eliminating tedium from your day; it’s also about reducing error. There’s a rule in programming that you should eliminate duplicate code wherever possible, because inevitably someone will change one part of the code and forget to change the other. The same is true of processes. Let’s say you must increment a version number each time you build a package; inevitably someone will build the package but forget to increment the version number. Now you have two packages floating around that are different yet have identical versions.

Obviously, the way to eliminate this error is to make the process automatic. The computer, when told it must increment the version each time it does a package build, will repeatedly demonstrate its ability to follow orders.

Actions

The best automation tool depends entirely on the job you’re trying to automate. However, there are a few common tasks that every programmer gets saddled with.

Build

(examples: Ant, Maven, Make, Rake) These are dependency-driven tools that are mostly used for compiling code. Generally, C programs use make, and Java programs use ant or Maven, but there are no strict rules—the tools are general purpose.

Starting with the tool your company uses, create a simple project from scratch and learn to automate some tasks. For example, with C or Java, make a dependency rule that automatically compiles files when they change. Make a test target (make test or similar) that depends on all files being compiled and then runs unit tests. Finally, make a documentation target that runs JavaDoc—or whatever is appropriate—to create doc files.

You’ll notice that targets can have dependencies—for example, unit tests require that all source files are compiled—and the tool will recurse as necessary to fulfill them in the correct order.

Packaging

(examples: RPM, APT, InstallShield) Each operating system has its favored packaging system, and it’s usually an uphill battle to do your own thing, so don’t. Packaging is mundane, but it’s a tremendous time-saver when you need to deploy code. Further, its automatic dependency resolution can save you from a whole host of errors.

Pick a packaging system and make a simple “Hello World” application. Then package your application for distribution. If you’re on Linux, for example, make the package install your app to /usr/bin/hello. Now for some fun (for a very nerdy definition of “fun”). First, install and uninstall your package. The application should get removed when the package is uninstalled.

Install your package again. Next, increment the version of your package and move the install target, for example, to /usr/local/bin/hello. Now upgrade to the new version of the package. Your old application should go away, and the new one should be in its correct spot.

Finally, use your build automation tool to create the package for you. Now you can use one command to go from source code to a deployable package. Cool, huh?

System Administration

(examples: too many to list) Buy a book on system administration; you’re guaranteed to find a lot of things your operating system can do to relieve burden. On Unix, cron can run tasks at regular intervals, ssh can run commands on remote systems, find can find new or stale files for you, and so forth. Learn ten new commands over the next two weeks.