The Five Rules I Do Not Break on Sundays

Sunday is the most dangerous day of the week for me. The market is closed, the inbox is quiet, the feed is full of weekend takes I do not need to respond to. I have a free afternoon and a system that has been running unattended for six days. The temptation to open the editor and start fixing things is constant.

The problem is that nothing I touch on Sunday gets exercised under load until Monday at 06:30 Pacific, and Monday morning is the worst possible time to discover that my last "small cleanup" broke a code path I had not thought to test. After enough of these self-inflicted incidents, I wrote down five rules for myself. They are deliberately boring. The point is to remove the decision, not to make it well.

1. No production deploys after Friday market close

This one cost me the most to learn. Trading-system fixes that look obvious on a Sunday afternoon almost always fail to account for the open-market state the system enters on Monday. A change to the bracket-order logic that passed every unit test deployed quietly on a Sunday last fall, and on Monday at 09:35 Pacific the first signal that fired hit a code path I had refactored at 14:00 the day before. The order went through. The stop did not. I had to manually flatten before lunch.

The rule now: if a change is worth deploying, it is worth waiting until Tuesday morning to deploy, with the full week of market hours ahead to catch any regression. Friday-evening-through-Monday-morning is a freeze.

2. No reading my own dashboards before noon

I have a daily P&L dashboard, a positions dashboard, a regime-state dashboard, and a content-engagement dashboard. Each of them is fine to look at when there is something I plan to act on. None of them is fine to look at over coffee on a Sunday.

The reason is selection bias on attention. If I look at the regime dashboard on Sunday morning, I see whatever Friday's close left me looking at, and I will spend the next two hours building a hypothesis about what to do Monday. Six times out of seven that hypothesis is worse than the rule the system is already following. The other one out of seven is a real signal, and a real signal will still be there at 12:01.

3. No new code on a Sunday

This is stricter than rule one. Even if I am not deploying, I do not write new code. The reason is that code I write on a quiet Sunday is code I will be tempted to deploy on the next quiet Sunday. The temptation compounds. The fix is to remove the input.

What I will do is read code: my own logs from the week, a paper that has been open in a tab for three weeks, the source of a library I have been using without understanding. Reading on Sunday is fine. Writing on Sunday turns into deploying on Sunday.

4. No system-wide changes without a written before-and-after

If I do find a real bug on a Sunday, I am not allowed to fix it Sunday. I am allowed to write down two things: what the system does today, and what I want it to do instead. Both in plain English, in a file. If I cannot write the before-and-after in three sentences each, I do not understand the bug well enough to fix it.

This rule has saved me from at least four "fixes" that would have changed the wrong thing. Twice the act of writing the before-state out clearly was enough to realize the system was already correct and I had misread the log.

5. The weekly review is the only Sunday work that counts

The one thing I do let myself do on Sunday is the weekly review. Read every trade the system took. Read every blog post I published. Read the engagement log. Note three things that surprised me and one thing I want to change. The change does not get implemented Sunday. It gets a line in a file, and Tuesday morning I either still believe it or I do not.

The review is cheap. It is the only Sunday output I trust, because it cannot break anything.

The pattern

These five rules are about one thing: a solo operator running automated systems is the bottleneck, and the bottleneck is most expensive on the days when nothing is forcing structure on the day. The market enforces structure Monday through Friday. The weekly review enforces structure on Sunday. Saturday I just take off.

If you are running a stack alone and you find yourself fiddling on weekends, the question to ask is not "is this fix good." It is "what is the worst version of me going to do with this same Sunday afternoon a month from now." Write the rule for that version. Mine has thanked me five times this year.