Asking for code you could not have written

You do not need to become a programmer

You need to get a specific job done: rename 400 files, pull data out of 30 PDFs, convert a folder of images, split one spreadsheet into twelve. These are twenty-line scripts, and asking for one is now realistic for somebody who has never written code.

What you do need is the ability to run it safely and to tell whether it worked. That is a much smaller skill than programming, and this lesson is that skill.

Asking well

I am on macOS and have never used Python. Write a script that goes through every PDF in a folder, pulls out the invoice number and total, and writes them to a CSV.

Tell me: what to install, exactly what to type to run it, and what should happen. Add a comment on every line explaining what it does. Do not delete or modify any original file. Print the number of files processed at the end.

Five things doing work: your platform and level, the task, the setup instructions, comments per line, and (most importantly) the instruction that nothing gets modified or deleted.

The safety rules, which are not optional

1. Work on a copy. Always. Copy the folder first, run the script on the copy. This one habit makes every other risk survivable.

2. Never let a first run delete, overwrite or move. Ask for a dry run: “print what it would do, do not do it.” Read the output. Then run it for real.

3. Read the script for four things, even if you do not understand the rest:

• Anything that says delete, remove, rm, unlink, overwrite, w mode on a file you care about.
• Any path outside the folder you intended.
• Any network address: a script for local files should not be sending anything anywhere.
• Any request for a password, key or account credential.

4. Never paste in a credential. If a script wants a password or an API key, that is a moment to stop and ask somebody, not a step to complete.

5. Do not run something you cannot explain in one sentence. If you cannot say what it does, ask for it to be explained until you can. “I don’t understand it but it worked” is how people lose a folder.

Checking that it worked

• Count. 400 files in, 400 rows out. A short count is the commonest failure and the easiest check.
• Spot-check three. One from the start, one from the middle, one from the end. Open the original and compare.
• Look for empties. A column that is blank for 40 rows means the extraction failed for those, silently.
• Try a deliberate oddity. Put one badly formatted file in and see whether it is reported or ignored. A script that skips what it cannot parse without saying so is worse than one that crashes.

When it does not run

Paste the entire error message. Not a description of it: the whole thing, including the file name and line number. Add what you typed and what you expected. This is the context lesson applied to your terminal, and it usually resolves in one turn.

The free path, and what it costs

Python is free and pre-installed on macOS and most Linux systems; on Windows it is a small download. VS Code is free. So is everything you need for this.

The honest cost is that generated code often works on the happy path and fails on the ragged edges of real data: the file with no text layer, the row with a comma in the wrong place, the encoding that is not UTF-8. Expect to go two or three rounds, and expect the failures to be about your specific data rather than about the logic.

Where to stop

Anything touching production systems, customer data, payments, or a database somebody else depends on is not a place to run code you cannot read. That is not caution for its own sake: the failure mode there is not a lost afternoon, and the person who has to unpick it will not be you.