The working rules

Print it. Put it beside the laptop. Every rule here exists because somebody lost a show, a file, a deposit or a finger, and every one of them is a rule you can be sent home for breaking.

The four that are never negotiable#

1. Nothing a model wrote goes between a performer and a machine. A large language model may help you write code that makes an effect happen. It is never the thing standing between a person and something that moves, heats, carries mains or restrains. Interlocks are hardware. Limit switches are wired. The emergency stop is hardwired, removes power, and asks no processor for permission.

2. Run it on a copy first, every time, without exception. The first run of any script has a bug. Yours, a colleague's, or a model's. A copy costs ten seconds and a --dry-run flag costs one line. Two hundred files renamed wrongly costs a day, and two hundred files deleted costs whatever they were worth.

3. Never run code you cannot answer the four questions about. What state does it hold, what does one pass do, what does it assume, what happens when it is wrong. If you cannot answer all four, you do not understand it well enough to be responsible for it, and you are about to be responsible for it.

4. The show machine is not your development machine. No package installs during a run. No automatic updates. No editing the live file to try something. Change it on a copy, prove it, then deploy it. "I will just quickly" is how the second half of a performance is lost.

Before you run anything that writes#

Five seconds, every time. It is the code equivalent of live, dead, live.

1. What does this write to, exactly? Name the path out loud.
2. Is that a copy? If not, make one.
3. What happens if it is half done when it stops? Half-renamed is worse than not renamed.
4. Can I undo this? If the answer is no, do not run it yet.
5. Is anything else using these files right now? Including a program that has one open.

Anything that deletes gets a sixth: read the deletion line character by character. A wrong variable in a delete is the one mistake in this course that cannot be walked back.

Working with AI, the standing rules#

Never paste: credentials, API keys, .env files, private keys, personal data, contracts under NDA, unreleased creative material, the venue's network diagram with addresses on it.

Always verify: anything about your specific rig, any function name you do not recognise, any number that arrived without a source, and every path that gets written to or deleted.

Always disclose: in the commit message, in the handover, and to a client if their terms require it. Not because it is shameful. Because the next person needs to know what was verified and by whom.

Never say: "the AI wrote it", in an incident report. It is not a defence, it has never been accepted anywhere, and your name is on the risk assessment.

Files and version control#

Commit before you try something. The commit is the undo. It costs eight seconds.

Commit messages say why, not what. The diff already says what. "Fix DMX offset: patch is 1-based and the array is 0-based" saves an hour in three weeks. "changes" saves nothing, ever.

One repository is not a backup. A repository on a single laptop is one flight case away from being no copies. Push it somewhere else, routinely, on purpose.

Dates as YYYY-MM-DD. They sort correctly, which means alphabetical order and chronological order are the same order, which means the newest file is always at the bottom.

Never keep versions in filenames if you have version control. Pick one system. Two systems is no system, and FINAL_v3_REALLY_FINAL is what no system looks like.

A README in every project folder. What it is, how to run it, what it assumes, who to ask. Ten lines. It is the whole difference between a tool and a liability.

Show hardware#

Set every pin explicitly in setup(), before anything else, and arrange the hardware so the de-energised state is the safe state. What a pin does in the microseconds before your code runs is decided by the board, not by you.

Never delay() in anything that matters. millis() timing from the first line. Converting later is a rewrite and it always falls in show week.

Compare times as millis() - started >= interval. The other form breaks when the counter wraps at about 49 days, and an installation that fails once every seven weeks is a genuinely horrible thing to be handed.

Every effect has a defined loss-of-signal behaviour, written down before it is built. Six lines of code, one constant, and a sentence in the documentation saying why that number.

Write the boot time on the case. Stage management needs the number, not a surprise.

When it goes wrong, in front of people#

Say what you know, not what you hope. "It has stopped responding, I need two minutes to establish whether it is the network or the machine" is a professional sentence. "It should be fine" is not.

Change one thing. Under pressure the urge is to change three. Then you have learned nothing about any of them and cannot get back.

Write down what you did, while you are doing it. Afterwards nobody remembers the order, and the order is the entire evidence.

Establish the boundary before you touch anything. What works, what does not, and where the line between them is. The fault is on that line. This is the same method as the multimeter and the same method as the packet capture, and it is the only one that works when you are tired.

Restarting is a diagnostic step, not a fix. It is allowed. Note that you did it, and note that you have now destroyed the evidence.

The three sentences worth memorising#

The computer does not know what you meant. It only knows what you wrote.

Never run code you cannot answer the four questions about, whoever wrote it.

If you cannot say what it does when it is alone and confused, you have not designed it yet.