Task automation: start with the small job you keep putting off

Renaming a folder of files is not much of a project until it is your folder, your deadline and your third attempt to keep the names consistent. A few lines of code can be enough to make the job less irritating.

Task automation starts well at that scale. You can see the input, describe the rule and check the output. This guide includes a Python preview that proposes changes without renaming anything, alongside a worked stock-check example. Pick the part that resembles your own annoyance and try it on a copy first.

Choose the small, repeatable part

Do not start with a heroic savings forecast. Measure roughly how long the task takes, how often it happens and how many people repeat it. That is enough to decide whether a small experiment is sensible.

• It happens often enough to be annoying.
• The steps are mostly the same each time.
• The input is available in a form software can read.
• A mistake is detectable and recoverable.
• The person doing it would happily stop doing it.

Example: prepare a weekly stock-check list

Imagine a shared equipment cupboard. Once a week, somebody copies items due for inspection into a checklist. A first automation can prepare that list from an existing register and leave the checks themselves to a person.

Use an item ID and the inspection period to identify one checklist entry. Missing dates should go to a review list rather than being silently ignored. A second run for the same period should update or reuse the draft, not create extra inspections.

Count the time after checking

For illustration, a task taking 10 minutes, repeated 10 times a week by two people, uses 200 minutes. Removing 70% gives 140 minutes before maintenance. A 30-minute weekly checking allowance leaves 110 minutes, about 1.8 hours. These are sample inputs, not measured savings.

At 46 working weeks, that is about 84.3 hours before setup. Eight setup hours bring the first-year estimate to about 76.3 hours. Change these assumptions in the calculator; an automation with negative net time may still teach you something, but it has not saved time.

Write a handover that survives a holiday

Record the source file, expected run time, owner role and manual procedure. Include an example of a good output and where failures appear. Somebody other than the builder should be able to stop it.

Run a short observed trial before changing the normal process. Keep a note of corrections and failed runs alongside the time estimate. If the workload changes, recalculate rather than reusing the old result.

A small script can be the whole project

Suppose you keep photographs of a hobby build in a folder, with filenames that make sense to the camera but not to you. The first useful automation could list proposed new names beside the originals. You can review that list before a separate step makes any changes. A preview is already an improvement if it removes the mental work of inventing and checking each name.

Give the script one folder rather than your entire computer. Work on copies and decide how to handle two files that would end up with the same name. A date alone is rarely a unique identifier. If the input is a spreadsheet export, keep the original export unchanged so you have something to compare against when a result looks odd.

Python's csv module reads rows as lists or dictionaries. Use a CSV reader rather than splitting text at every comma: quoted fields can contain commas of their own. The pathlib module gives you a readable way to work with paths. Those two standard-library features can support a useful file-preparation tool without a dashboard, a subscription or an AI model.

Sources: Python: reading and writing CSV files, Python: pathlib.

Make a plan before changing files

Here is a small example you can adapt. Create a CSV called files.csv with the columns original and proposed, using made-up filenames for the first run. The script below prints a rename plan and rejects repeated destination names. It deliberately does not rename anything. That makes the output easy to inspect and lets you test the rules separately from any filesystem changes.

Try three inputs: two distinct new names, two rows with the same proposed name and a row with an empty destination. The first should print the plan; the other two should stop with an explanation. This example treats names as plain labels. A later implementation that touches files must also check directory boundaries, existing files, filesystem case rules and whether any destination would overwrite a source.

import csv

with open("files.csv", newline="", encoding="utf-8-sig") as source:
    reader = csv.DictReader(source)
    if not {"original", "proposed"}.issubset(reader.fieldnames or []):
        raise ValueError("Use original and proposed columns")
    rows = list(reader)

seen = set()
for row in rows:
    original = (row.get("original") or "").strip()
    proposed = (row.get("proposed") or "").strip()
    if not original or not proposed:
        raise ValueError("Each row needs both names")
    if proposed.casefold() in seen:
        raise ValueError("Repeated destination: " + proposed)
    seen.add(proposed.casefold())

for row in rows:
    print(row["original"].strip(), "->", row["proposed"].strip())

Choose when it runs

A button you press can be a perfectly sensible trigger. You know the source files are ready, you can watch the output and you can decide whether to continue. Moving to a schedule only helps when the input is reliably available at that time. A weekly job that quietly reads last week's export has made the wrong thing more punctual.

For a scheduled task, include the source date or period in the output. An empty input should be distinguishable from a failed import. If nothing needs doing, record that fact in a short status message rather than generating an alarming error or silently producing an old result. Someone checking the job on Monday should be able to tell which situation happened.

Be careful with shortcuts triggered by your own output. A script that watches a folder and then writes into the same watched folder can start itself again. Keep input and output locations separate, or define a clear exclusion rule. Test a second run before leaving the process unattended. It is often the second run that reveals what the first demonstration concealed.

Useful can mean easier, quieter or more fun

Time saved is only one reason to build. A large physical button that prepares a familiar workspace may make a computer easier for somebody to use. A script that checks whether a backup file exists can remove a nagging uncertainty. A silly desktop counter might simply give you a reason to learn how events work. State the purpose before deciding how to judge the result.

If you are building for another person, ask them to try the manual version first. Find out which part actually gets in their way, what feedback they need and whether they can undo a mistake. Their preferred sequence may differ from yours. The smallest helpful change might be clearer filenames or a single shortcut, rather than a process that runs while they are not watching.

Bring the script and one example input to a Show & Tell. Show what the person used to do, run the preview and explain the case that made you change the rules. A short file with a clear purpose gives other people something they can adapt on their own machines. It also leaves plenty of room for the next person to show a completely unnecessary gadget.

Sources and further reading

• n8n: handling workflow errors. Primary documentation for failure workflows, rather than evidence of a particular time saving.
• Python: reading and writing CSV files. Standard-library readers and writers for structured tabular files.
• Python: pathlib. Path objects and filesystem operations. Check operation behaviour before changing files.

Continue with

• Workflow automation: start with the job nobody wants to do twice