What Is a Good Shitty First Draft

The shitty first draft philosophy refers to a workflow in writing as well as programming where you focus on getting your core ideas down and ignore as much corrective work as possible until you’ve completed the first draft.

Writing a shitty first draft is generally good advice as it cultivates concentration and guards against writer’s block. It’s worth noting, however, that when practiced recklessly it can have damaging effects on software architecture and can hinder progress.

An ungroomed codebase paralyzes developers and prevents work from getting done because things are hard to find and understand, there’s a cacophony of spaghetti code, and touching something feels like it will break other parts of the application.

Rather than coding a shitty first version outright, we should instead set our priorities straight.

The minimum viable product, or MVP for short, is a good mental framework not just at the beginning but throughout the entire lifespan of a project. It simply asks, what are the core qualities that your product or feature can’t live without?

For example, if you’re building a blog you’ll need a list of blog posts and pages for individual posts. Do those first. Reader comments? Probably not an immediate requirement. Keep a backlog of nice-to-haves but ignore them for now. Just focus on what truly matters.

A shitty first draft should not be a mess. It’s just a smaller draft that contains fewer features but doesn’t sacrifice quality or structure.

The MVP mindset can be applied to smaller things too. Think what’s absolutely necessary and what is discardable. If you’re building a navigation menu, make the links work and worry about cosmetic effects later. Make sure the code is clean and flexible so that you and other developers can effortlessly get back to it later.

Feel free to write smelly code when trying things out, just don’t commit it to the repository. Whenever you commit bad code you collect technical debt that will need fixing in the future. Once the amount of debt becomes unmanageable, you’ll be forced to declare technical bankruptcy. This is when ordinary application development stops and the developers must decide whether to refactor the codebase or start afresh. Either way, the work needed to undo bad coding practices is exorbitant.