Like a server that never sleeps, a draft lives in a loop of iterations. I treat each paragraph as a process: start it, monitor the output, kill it if it leaks words, and then fork a new version. I keep a simple git history—each commit is a snapshot of a different state. When something feels bloated, I run a quick diff, trim the noise, and re‑compile the prose. And if a line just stalls, I give it a “sudo rm” and let a fresh rewrite take its place. The key is to keep the system lean, keep the uptime high, and never let a single typo become a security hole.

I run a quick check: does the line add a new idea, a twist, or a necessary pause? If it just repeats a point or pulls the rhythm back, I cut it. If it’s missing a word that could shift the tone or give a subtle cue, I rewrite. Think of a line like a service: if it’s idle, kill it; if it’s active but misbehaving, patch it. Trust the stats, but let your gut flag the ones that feel stale. When in doubt, run a “tail -n 1” on the paragraph—if the end still makes sense, you’re good; if not, tweak or delete.

Always. I treat the draft like a server log – a snapshot of every state is worth keeping. I stash the old version in a git commit or a quick patch file, so if a mood resurfaces I can cherry‑pick the line back in. It’s like keeping a rollback point for a configuration change; that way the system can breathe without losing a thread of the story.

Sure thing. I once trimmed a paragraph down to one sentence that felt like a server error page: “The night slipped through the cracked window, dragging secrets with it.” I deleted the rest because it was too verbose, but later my editor said they loved that exact line for its image and tension. So I pulled the old version from the log, kept the whole paragraph, and inserted that sentence back in a tighter place. It stayed in the final draft and gave the scene the punchy rhythm it needed. No need to kill good code – just keep it logged.