j. / Jacob

Technology & systems

Before you automate, make the task smaller.

By · Published · Updated · About 5 minutes

A repeated task is a candidate for automation, not an obligation. Start by deciding whether it needs to happen at all. Then make the smallest useful version dependable before expanding it.

1. Write down one complete run

Pick a recent, ordinary example. Record the input, each decision, the output and how you knew it was correct. “Handle the weekly report” is too broad. “Combine three exported files and flag missing rows” is specific enough to examine.

Separate mechanical steps from judgment. Renaming files may be mechanical. Deciding whether an unusual expense is legitimate needs context. Keep that decision visible instead of burying it in a rule.

2. Count maintenance, not just minutes saved

Estimate the time per run and frequency. Then include setup, checking results, fixing failures and adapting when the input changes. A five-minute weekly task saves about four hours a year before maintenance; a complicated solution may cost more attention than it returns.

A useful first version can be a checklist, a saved query or a script you run yourself. A schedule is worth adding only when unattended execution has a clear benefit and a clear failure path.

3. Define the boundary

Write down what the automation may read, what it may change and what it must never do. Use the minimum access needed. Keep credentials out of source files and avoid copying customer or employer data into tools that are not approved for it.

  • Input: which files or records are expected?
  • Validation: what makes an input invalid or incomplete?
  • Output: what result should a normal run produce?
  • Repeat: what happens if the same input arrives twice?
  • Recovery: can you undo the change or safely run it again?

4. Start with a reviewable result

For example, a file-cleanup script can first list proposed renames without touching anything. Compare that list against a small set of sample files, including duplicates and missing fields. Only enable changes once the preview is understandable.

For actions that send messages, delete records or spend money, keep a human review step until the failure cases are understood. A silent partial success is often harder to repair than an explicit failure.

5. Try a dry run, a failure and a recovery

This is an illustrative filename exercise. Use two disposable text files in a test folder and keep an untouched copy. The proposed change is to add reviewed- to each original filename.

  • Dry run: show notes-a.txt -> reviewed-notes-a.txt and notes-b.txt -> reviewed-notes-b.txt. Change no files. If either target already exists, flag a conflict and stop; do not overwrite it.
  • Apply in the test folder: keep a log of each original name, target name and result. Imagine the first rename succeeds but the second fails because the file is locked. Stop and record the partial result instead of reporting the whole batch as complete.
  • Recover: release the lock, compare the completed target with the untouched copy, and check that the remaining target is free. Retry only the failed original-to-target pair. Do not build a fresh rename list from the current filenames: that could add reviewed- twice.
  • Verify: both expected names exist, the file count is unchanged and their contents match the untouched copies. If the log or contents are uncertain, discard only the disposable test folder and start again from the copies.

6. Decide how it earns its place

After a few real runs, ask: did this save attention? Can I explain a failure? Could I stop using it without creating a mess? Keep a short note with its purpose, inputs, owner and recovery steps.

If the task changes constantly or still needs extensive checking, keep it manual for now. That is a valid design decision.

General educational guidance. Adapt it to your environment, permissions and risk. Examples are illustrative unless identified as project history.

← Back to all guides