Small enough to hold in your head

The temptation

You sit down to automate one thing and within an hour you are building a framework: configuration files, a plugin system, handling for four cases that have never happened. This feels like good engineering. It is the commonest way first automations die — not from failure, but from never being finished.

The discipline

Build the version that handles the normal case only, and that you could read aloud in under a minute. If a weird case shows up, let it fail loudly and deal with it by hand this once. You will learn more from three real weird cases than from ten you imagined.

Two rules that pay off immediately

Do the check before the action. Look first, act second. Confirm the source exists, the destination is reachable, the input is the shape you expected — then do the work. Most automations that cause damage do so by acting on an assumption they never verified: writing to a folder that was not mounted, copying from a directory that was empty.

Make it say what it did. Not a debug log for you — a plain line a stranger could read: “copied 14 files, 3.2 GB, skipped 2 already present”. This one line is worth more than any amount of internal logging, and it is what you will read in six months when you have forgotten everything.

Run it by hand, repeatedly, first

Before you attach any trigger, run it manually five or six times, including on days when there is nothing to do. An automation that behaves badly when there is no work — errors out, sends an alarm, does something odd — will do that most days, and you will start ignoring it. The quiet no-op case is the most common case and it is almost never tested.

Then, and only then, attach the trigger

Attaching the schedule is the last step, not the first. Up to that moment you have a tool you run. After it, you have a system that runs itself, and everything gets harder to observe.