Open Process: Ship It (What Code Reviews Can Teach Us About Script Notes)

This post is part of Open Process, our series about what it actually looks like to make new work: messy drafts, real questions, useful frameworks, and the moment you decide to show the thing before it’s “done.”

At first glance, the world of software engineering and the world of playwriting couldn't be further apart. One is governed by cold, hard logic, semicolons, and binary; the other by the ephemeral "vibe" of a character, the subtext of a pause, and the messy unpredictability of human emotion.

But if you look at the process of how both things are made, the Venn diagram starts to look like a circle. Both involve a creator sitting in a dark room, building something out of nothing, and then, here’s the scary part, showing it to other people to find out where it’s broken.

In the tech world, this is called a Code Review. In our world, it’s Giving Notes.

The problem is that the tech world has spent the last thirty years optimizing this process to be as efficient, blameless, and "shippable" as possible. Meanwhile, in the arts, we’re often still stuck in a cycle of ego-bruising "thesis defenses" where the writer feels judged and the note-giver feels like a critic rather than a collaborator.

So in true Open Process spirit: let’s steal the parts that help. Welcome to the "Ship It" edition.

The Death of a Thousand Nits

In software engineering, there is a phenomenon known as "The Death of a Thousand Nits." A "nit" (short for nitpick) is a tiny, trivial suggestion. Maybe it’s a variable name that could be clearer, or a slightly more elegant way to write a loop that doesn't actually change how the program runs.

When a developer submits a "Pull Request" (a request to merge their new code into the main project), and a reviewer comes back with 50 nits, it kills the momentum. The developer spends three hours fixing typos and stylistic preferences while the actual, massive logic bug in the middle of the code goes unaddressed because everyone is exhausted by the "nits."

Does this sound familiar?

You hand over a 90-page draft of a new play. Your reader returns a document where 80% of the comments are about a character's shoe choice or a typo on page 14. By the time you get to the note about the fact that your protagonist has no clear motivation, you’ve already checked out. You’re defensive. You’re tired.

In tech, the best teams use the "Nit" Tag.

The "Nit" Tag: Separating Style from Logic

Google’s engineering practices and legendary resources like The Pragmatic Engineer emphasize a simple rule: Distinguish between what is "blocking" and what is "suggestive."

In a Code Review, a reviewer will literally type "Nit:" before a comment. This signals to the author: "I noticed this, and I think it could be better, but it is not a reason to stop this code from being published. If you disagree, ignore it and move on."

In Notes 2.0, we should be doing the same. As a note-giver, you should be categorizing your feedback:

• Logic/Structure (The "Breaking" Bugs): "I don’t understand why the protagonist leaves the room here. If they leave, the rest of the play doesn't happen." (This is a blocker).
• Nit (Stylistic Preference): "Nit: I feel like this character would drink scotch, not gin." (This is non-blocking).

When a writer knows which notes are "nits," they can "Ship It", meaning they can move the draft forward without getting stuck in a quagmire of subjective preferences. It allows the writer to maintain their voice while the community helps them fix the structural plumbing.

PR Culture: The Power of the "Commit"

In software development, you don't write an entire operating system and then ask for a review. You work in "commits", small, manageable chunks of work. You then open a Pull Request (PR), asking your peers to review that specific chunk.

We often treat script development like we’re building a cathedral in secret, only showing it when the roof is on. But at The Orchard Project, we’re obsessed with the idea of the writer’s room as a problem-solving engine.

As Ari Edelson often says: "What happens during a writer's room is you get given the opportunity to stand up in front of each other and say, I have a list of problems. Here are my 10 problems. Why don't you all solve them for me?"

That is pure PR culture. Instead of saying, "Here is my play, please tell me if it’s good," a Notes 2.0 approach says: "I’ve committed a new version of Act 2, Scene 1. I’m struggling with the transition at the end. Can you look at this specific 'commit' and help me solve the logic?"

By shrinking the "ask," you increase the quality of the feedback. You aren't asking for a judgment on your soul; you’re asking for a fix on a specific narrative "bug."

Blameless Post-Mortems: Focus on the Bug, Not the Coder

When a major website like Google or Etsy goes down, they don't hold a meeting to find out who to fire. They hold a Blameless Post-Mortem.

The goal isn't to point fingers; it's to look at the system. Why did the code allow this mistake to happen? What was the "bug" in the logic?

In a traditional script meeting, if a scene "bombs," the writer often feels like they have failed. The room becomes a courtroom where the writer is on trial. This is what we call a "judging dynamic."

To get to a "joining dynamic," we have to treat the script like code. The script is a separate entity from the writer. If a scene isn't working, it isn't because the writer is "bad"; it’s because there is a bug in the narrative "software."

When we look at our portfolio of work, the projects that thrive are the ones where the artist treats their draft as a prototype. They aren't defending a PhD thesis; they are running a lab.

As Ari puts it: "This is not a PhD defense. This is actually an opportunity to flip it around and say, I am running a room to solve problems in my storytelling."

Why "Ship It" Matters for Artists

The phrase "Ship It" is a mantra in Silicon Valley. It means that the product is good enough to be used, even if it isn't perfect. In the arts, we are often paralyzed by the "Perfect Draft" myth. We hold onto scripts for years because we’re afraid of the "nits."

But storytelling, especially in episodic TV or developmental theater, is about momentum.

In code, "Structure is not formula; structure is momentum." The same is true for a script. If you can move from a judging dynamic ("Is this good?") to a problem-solving dynamic ("Does this work?"), you gain the propulsive energy needed to actually finish the damn thing.

By adopting a "Ship It" mentality, you give yourself permission to:

1. Request feedback on "commits" (scenes/outlines) rather than just finished drafts.
2. Ignore the "Nits" to focus on the structural "Blockers."
3. Use your "room" as a group of co-developers who are there to help you debug, not to act as a jury.

The Orchard Project Approach

We’ve seen this work firsthand in our Episodic Learning Lab and our various incubators. The writers who make the most progress aren't necessarily the ones with the most "polished" first drafts. They are the ones who are the best "filters" for the room’s resources.

They hear the chorus of ideas, ignore the nits, identify the structural bugs, and, most importantly, they keep "shipping" new versions.

If you’re sitting on a draft right now, paralyzed by the thought of what people will say, try changing the framework. Don't ask for a review of your "art." Open a "Pull Request" for your "logic."

Tell your readers: "Hey, I'm shipping this draft. Mark your stylistic preferences as 'Nits,' but please let me know if you find any 'Blockers' in the Act 2 emotional arc."

You’ll be amazed at how much faster you can move when you aren't afraid of a few bugs in the system.

---

Want to dive deeper into the Orchard Project's philosophy on creative development? Check out our Team Page to see the humans behind the "problem-solving engine," or browse our Testimonials to see how this approach has helped artists ship their most ambitious work.