Run a Dry Run First, Then Hit Confirm: Make It Muscle Memory

Let’s start with a real-world scenario: A friend working in DevOps ran a "clean up expired logs" script at 8 AM one morning. The script itself was fine; the mistake was that he overlooked a path variable, writing `/data` instead of `/data/tmp`. Twenty minutes later, the entire data directory was wiped. If he had run it with `--dry-run` first, the terminal would have printed a list of directories slated for deletion—he would have spotted the error immediately.

The One-Sentence Rule

**For any operation where undoing is costly, run a preview/dry run first to confirm exactly what will be affected, then execute the real version.**

A dry run isn’t testing; it’s the "final brake before hitting the confirm button."

Specific Use Cases

**1. Batch changes to files and databases.** Renaming 500 files at once, bulk-updating 2,000 records, or migrating directory structures. Correct approach: Run with `--dry-run` or `explain` first, save the "list of objects to be changed" to a file, manually spot-check 10 items, and only proceed if the counts match.

**2. Changing configurations.** Nginx reverse proxies, systemd services, crontabs, SSH configs, CI pipelines. Correct approach: Validate first (`nginx -t`, unit test dry runs, `cron` trial runs), and take a look at what the current live configuration looks like before deciding on the minimal scope of changes.

**3. First-time deployment to production.** Launching a new domain, enabling a new format site-wide, or pushing a new template to all readers. Correct approach: Send yourself a draft link and walk through the entire flow—view pages, click links, check response headers—before rolling it out to everyone.

**4. Letting AI or scripts touch real assets for the first time.** The first time you let an automated tool delete files, send emails, or change schedules. Correct approach: Have it output "what I plan to do," you confirm the list, and only then grant execution permissions.

When You Don’t Need a Dry Run

- **Small changes reversible within three seconds**: Fixing a typo, renaming a file, recalling a message just sent. Doing a dry run for these only slows you down.

- **No preview mechanism available, and none can be created**: Some one-off operations lack a dry-run switch. In these cases, substitute with "backup + small steps": export first, test on a single record, then roll out in batches.

- **You are already executing a rollback plan**: A rollback is inherently "doing the opposite," so doing a dry run is paradoxical. Just execute it and monitor the status closely.

Pre-Execution Checklist

- [ ] Can I state in one sentence what this operation "will change"? (If not, you’re not ready.)

- [ ] The dry run output has been **saved**, not just scrolled past on the screen.

- [ ] I’ve spot-checked the first few lines, the last few lines, and the total count of the diff, rather than just glancing at it.

- [ ] The rollback method is currently available (commands are still in the terminal, backups are on disk), not just "I remember how to roll back."

- [ ] If the first dry run didn’t match expectations → Stop and fix it, then **run it again**. Don’t guess.

Common Pitfalls

**Pitfall 1: The dry run environment differs from the real execution environment.** Different permissions (you have them during preview, but the execution account doesn’t), different working directories, different time zones, different network states. The same command might "change 3 files" in preview but "change 30" in reality. Countermeasure: Run the dry run with the **same identity and directory** as the formal execution.

**Pitfall 2: Treating "dry run passed" as "guaranteed success."** A preview can’t account for concurrency, timing issues, or external API timeouts. A dry run only ensures "what you intend to change is indeed what you want to change"; it doesn’t guarantee the execution process will be accident-free. For critical failures, you need separate notification mechanisms.

**Pitfall 3: Overuse.** Requiring estimation, rehearsal, and approval for every single word change will bog down your workflow. There’s only one criterion: **If this change goes wrong, how many minutes will it take to recover?** If it’s more than 10 minutes, it’s worth a dry run; if not, just do it and ensure you have a clear undo path.

**Pitfall 4: "Glancing at the output" isn’t verification.** Human eyes are unreliable when scanning long lists, especially regarding numbers and units (3 files vs. 3,000 files). Save the output to a file, use `wc -l` to count the total, and use `head`/`tail` to check a few lines at the beginning and end. That counts as having checked it.

Wrapping Up

The value of a dry run isn’t technical; it’s about turning the "last 10 seconds before hitting confirm" from impulse into verification. Once you make it a habit, you’ll find that it doesn’t necessarily prevent "major disasters," but rather those silly mistakes that make you think afterward, "I just needed to take one more look."