Think Like a Software Developer to Improve Your Screenwriting
Over the course of my adult life, I’ve had my feet in two seemingly disparate worlds: creative writing (including screenwriting) and software engineering.
After a long career in web development, I transitioned (2.5 years ago) from the tech industry back to content production (which was my original focus after college).
Since then, in addition to blogging and audio/video production, I’ve spent a substantial amount of time on screenwriting. I’ve written (or re-written) three feature films and one short.
While working on my screenplays, I’ve applied numerous best practices from software engineering to my screenwriting process. I’ve discovered that software development and script development have a surprising degree of congruity.
With that in mind, below are six software development practices that may help you improve your screenwriting.
Use Open Source Languages & Free Tools
Software Development
Over the years, the software engineering field has moved away from proprietary programming languages (often requiring paid licenses) towards free open source languages. Moreover, many software engineers choose free coding tools to build their applications.
Script Development
Historically, for screenwriters, the industry-standard software for writing and correctly formatting screenplays has been Final Draft. The program (which currently retails for around $200) uses a proprietary file format (FDX), although it can import and export other formats.
Today, Final Draft is still wildly popular, but other options (both free and paid) are abundantly available. Also, and perhaps more importantly, screenwriting now has an open-source format of its own. Fountain text markup allows you to easily move your script between different screenwriting programs and text editors.
If you use Fountain syntax, you can write your script in virtually any text editing program — anything from a plain text editor (like Notepad) to a word processor (like Microsoft Word or Google Docs) to a dedicated screenwriting program (like Final Draft or Fade In).
That said, when you’re ready to publish your screenplay to PDF, you should use a specialized screenwriting program to auto-format your text.
Personally, I use a combination of tools during script development.
- I use Microsoft Word (on my Windows PC and iPad) to write and edit my screenplays (in Fountain syntax).
- I use the free version of WriterDuet to auto-format my fountain text to industry standard layout (font-size, margins, indentations, etc.).
- I recently used Trelby (a free screenwriting program for Windows and Linux) to generate a Character Report — to help me plan a table read. Reporting features are restricted in WriterDuet to the Pro version, but the beauty of Fountain is that you can mix and match which tools you use.
Perform Lint Checks
Software Development
Any coder worth their salt knows to check their code for syntax errors before submitting it for peer review or testing. In most cases, the first test will be to “lint” the code either with the checker built into the main coding tool or in a separate, dedicated tool or automated process
What is linting?
Linting is the automated checking of your source code for programmatic and stylistic errors. This is done by using a lint tool (otherwise known as linter). A lint tool is a basic static code analyzer.
(Source: Perforce)
If a developer were to skip linting and proceed with defective code, his or her application would likely fail to compile or crash at runtime.
Script Development
In screenplays, the equivalent of syntax errors is misspellings and grammar problems.
Like a good coder, a screenwriter should employ the best practice of using tools to check for these types of errors, as early in the writing process as possible.
Most writing programs have automatic spell checkers and many also have grammar checkers. For example, both Microsoft Word and Google Docs can check for misspellings as you type. They can also identify possible grammar issues. For me, Microsoft Word provides a robust first line of defense.
An even more powerful tool is Grammarly. After running the proofing tools in Microsoft Word, I copy and paste all of my scripts into Grammarly before publishing them. Grammarly usually finds numerous errors that Microsoft missed. Grammarly can integrate with both Word and Docs to check for errors as you type. I employ this technique in Docs, but I skip it in Word because I find the Microsoft integration clumsy.
Squash Bugs Early
Software Development
A truism in software engineering is that the cost of fixing bugs increases the later they are found in the software development life cycle.
The cost of detecting and fixing defects in software increases exponentially with time in the software development workflow. Fixing bugs in the field is incredibly costly, and risky — often by an order of magnitude or two. The cost is not just in the form of time and resources wasted in the present, but also in the form of lost opportunities in the future.
(Source: DeepSource)
To minimize the cost of bugs in software development, the best practice is to test in as many ways as possible at each step of the process, through some combination of manual and automated testing. Even better is to catch potential problems during the design process and solve for them even before coding begins!
Script Development
The same truism holds for screenwriting: the later you identify problems, the more painful and costly they become.
In addition to typos, misspellings, and grammatical mistakes, “bugs” in a screenplay can include all sorts of other errors. A few examples:
- Inconsistent or incorrect character names (e.g. you put the wrong name by accident above a line of dialogue).
- Failing to capitalize sound effects or the first appearance of character names in action blocks.
- Divergences from standard formatting conventions (e.g. putting “V.O.” in a parenthetical below a character name instead of next to it).
- Homophone errors (there vs. their, then vs. than, to vs. too, your vs. you’re, etc.). Grammarly usually catches these, but I’ve seen some get past it.
- Action blocks which go on for too many lines of code without enough white space line breaks, making them hard to read.
Now imagine that your script is riddled with these types of problems and consider how they can increasingly impact your success over the course of the creative development life cycle.
You may have written the next great American action movie, but if a reader bails on the script after ten pages because of formatting sloppiness and typos, then you’ve shot yourself in the foot.
Get Peer Reviews
Software Development
Code review (a.k.a. peer review) is an essential part of ensuring quality in software development.
What is code Review?
Code review is a phase in the software development process in which the authors of code, peer reviewers, and perhaps quality assurance (QA) testers get together to review code. Finding and correcting errors at this stage is relatively inexpensive and tends to reduce the more expensive process of handling, locating, and fixing bugs during later stages of development or after programs are delivered to users.
(Source: TechTarget)
Savvy software development teams not only formalize peer review as a required convention, they also build systems and processes that prevent unreviewed code from shipping. For example, in my last tech job as a Software Manager at TripIt, new code could not reach the main source control repository unless at least three peers had reviewed and approved the changes.
Script Development
Peer review is also a critical phase of screenwriting. At minimum, you should have at least one other person read your script to check for typos and grammatical errors.
Ideally, you should give your script to several people to read, especially fellow screenwriters or experienced industry readers. Try to find readers who can not only look for errors but also advise on story themes, character development, writing style, etc.
If you don’t know any other screenwriters or (like most people) don’t have any industry contacts, here are a few ideas for how to connect.
- Look for local screenwriting groups or meetups. My area, the Sacramento region in California, has several such groups.
- Look for online screenwriting groups (these are easy to find on Facebook or LinkedIn).
- Coverfly offers a free peer-to-peer script notes platform. I haven’t tried it yet, but it seems like a good option.
- Pay for professional coverage from an industry reader. For a price, many companies (and several screenwriting competitions) offer paid analysis. Many writers find this helpful to gauge the readiness of their script. Personally, I’ve relied on the first two methods and so far have not paid for coverage.
- Organize a table read for your script. Find ways to connect with actors in your community. You’ll likely find many who are eager to practice their craft and would welcome the opportunity to join your table read. You should also consider recruiting some audience members (possibly fellow screenwriters) to watch the read and participate in the feedback discussion.
Here are a two articles with useful tips for organizing a table read.
- Write, Direct, Repeat- Hosting a Table Read for Your Script
- How to put a table reading together for your film script
Use Diff Tools
Software Development
At the heart of peer code review in software development is the diff tool.
A diff tool allows one software engineer to easily review the additions, substractions, and changes made by another engineer.
Script Development
Many text editing tools, whether word processors (like Google Docs) or dedicated screenwriting programs (like WriterDuet), have native revision tracking (a.k.a. revision history) as a feature. In other words, they offer built-in diff tools.
As a screenwriter, why would you want to compare drafts of a screenplay in a diff tool?
I can imagine a multitude of use cases, but I’ll keep it simple and just describe examples from my own experience.
- Sometimes I’ve just needed a quick refresher on what changed between two previous drafts or what has changed so far in my current draft.
- If I’ve made only minor tweaks (a patch change) to a previous draft that I’ve already proofed, spell-checked, and published (e.g. for a reader or contest), then to save time, I can carefully proof just the changes since that draft. For example, rather than the laborious process of running the entire script through Grammarly again, I can check just the revised lines.
- I can give a reader of a previous draft a diff file, so he or she can review only my revised scenes instead of reading the whole script again. I’ve tried this only once so far, so the jury is out on this use case.
Plenty of free diff tools exist on Macs and PCs and on the web. For quick and easy, diffs, I usually use the web app Diffchecker.
Use Semantic Versioning
Software Development
Software developers use all kinds of version numbers for their applications.
Below, for example, is the version of Microsoft Word on my computer.
As a user, the arcane, long-winded number isn’t meaningful.
By contrast, many developers use a simpler semantic versioning system. Good examples are mobile operating systems and apps. For example, my iPhone is running iOS 14.1 (and 14.0.1 before that).
According to the conventions of semantic versioning, you update the version number according to the scope of the changes.
- Increment the MAJOR version when you make incompatible API changes.
- Increment the MINOR version when you add functionality in a backwards compatible manner.
- Increment PATCH version when you make backwards compatible bug fixes.
In everyday terms for the average user, major releases include significant new features and/or design changes, minor releases include small feature enhancements and patches include bug fixes. (In reality, all three types of releases typically include bug fixes.)
This type of versioning system gives a general sense of the scope of changes in a release. As a user, I understand that an upgrade from iOS 13.7 to 14 is going to be far more dramatic than an update from 14.1 to 14.2.
Script Development
In the world of screenwriting, the equivalent of version number is draft number (e.g. first draft, second draft, third draft).
Shooting scripts have specific conventions for handling revisions in order to minimize reprinting, but that’s beyond the scope of my expertise and this post.
By contrast, spec scripts (which is what most aspiring screenwriters are writing), do not have a standard draft versioning system, as far as I know.
So, for my own internal purposes, I have adopted semantic versioning for my scripts. For example, the current version of my latest script is 3.0.1. This tells me it’s a tweaked version of my third major draft.
More generally, I think of script versioning this way.
- I increment the MAJOR version when I have made substantial changes to the script, to a point where the revisions invalidate the previous draft. For example, I may have cut characters, changed major plot points, cut or reordered scenes, altered the tone, etc.
- I increment the MINOR version when I’ve made some minor improvements. For example, I may have shortened some scenes, improved some dialogue, rewritten some action blocks to be more concise or impactful, etc. However, the core nature of the script remains the same as the previous draft.
- I increment the PATCH version when I make trivial changes such as fixing typos, grammar problems and misspellings or if I make minutial changes to the characters, plot, or dialogue.
For the sake of illustration, here is the version history for my latest screenplay:
As compared to a simpler draft versioning scheme which might rely on whole numbers and/or dates, semantic versioning gives me more context about drafts that I’ve distributed for peer review or that I’ve entered into screenwriting competitions.
To preserve my script’s file history, every time I start a new draft (whether the new draft will be a major, minor or patch level change), I save a copy of the previous draft. In the example above, I have eight different Word files saved on my computer, one for each version between 1.0.0 and 3.0.1. If you use Google Docs, it allows you to “name current version” which is handy if you want to stamp a draft with a particular version number (similar to what I do with Word).
Your Turn
I can’t imagine that I’m the first screenwriter to draw parallels between screenwriting and software development. On the other hand, while writing this post, I couldn’t find anyone else on the web who had written about the topic.
What do you think? Am I stretching the comparison too far? Did I miss any other software engineering techniques that apply to screenwriting? Are any of these tips helpful?
I’d love to hear from you in the comments.