On Starting

Thanks to Pete Lacey’s tweet, I decided to turn the inability I was facing to come up with some useful concepts to blog about, into writing a post on the inability most people seem to face on starting something.

Pete gave me lemons, I'm going to see how I do making lemonade.

The Issues

I believe the issue most face with starting something, anything, a blog post, a software project, a book, a painting, can be reduced (for simplicity) to two main causes: won’t start or can’t start.

Lets start with the “won’t” camp.

Perfectionism

My belief is that the “won’t” people are afraid of what they produce not being good enough, either objectively based on peer review, or subjectively based off their own high standard. Ira Glass articulated this “Gap” between our taste vs. our ability beautifully in video form and in transcript form.

This hits us all, even Paul McCartney.

Just...stuck

Sometimes, the issue isn’t “this won’t be good enough”, its more, “how do I possibly begin??”. This could be due to inability to tackle a new problem, because you’ve got no experience in it, or, a plethora of solutions overwhelm you. Paralysis by analysis does exist and it is very real. I wrote Too Scared To Write a Line of Code 5 years ago and it still rings true, for me at least.

Remedies

Now I’ve identified what I believe to be the main causes, lets switch gears and head towards positivity; the remedies and antidotes for these issues.

Plan

A really useful technique I’ve employed recently for various completed works (blog posts, project proposals*, etc), and its an obvious one, is to map out the rough final result. An outline. Lets take a blog post. Lets take this blog post. I didn’t start at the top and write continue prose for ~500 words, my brain doesn’t seem to work like that. I mapped out several key points as headings and outlined the rough shape of the post. All I then do is fill in the gaps.

A captain maps a route to a final destination, they don't just write down, “sail to America”, but plan several points along the way to guide them.

*True story: I sat for a full 40 minutes yesterday, almost continuously, staring at a blank Notes.app file, trying to start a project proposal. Once I finally managed to start, the words fell out of me.

The secret to building large apps is never build large apps. Break your applications into small pieces. Then, assemble those testable, bite-sized pieces into your big application —Justin Meyer, author JavaScriptMVC

Don’t think about your final product as LARGE, DAUNTING, SCARY but several smaller pieces you can assemble.

Iterate

A fear I often, and irrationally, have is, “as soon as I [write this first line of code/create this first directory/write the intro for this post], it will define the final form, cemented forever”. That’s codswallop. It’s really hard to build on, or evaluate an empty page, or an empty code file.

Write or create something tiny and terrible, and then immediately begin improving it. I view software and writing rarely as creating, but just improving on previous ideas and solutions.

I think about the McDonalds Theory maybe once every 6 months. It’s fascinating to think about but also a hugely useful weapon to have in your arsenal. Especially if you’re suffering from analysis paralysis. Start with something intentionally awful, and you’ll have an immediate (undesirable) base to work from and improve.

Repurpose

I rarely start a brand new project from truly nothing. I’m fortunate enough to have built up a body of work, that, if I am starting something new, it’s likely that at least one of my previous projects, or certainly large parts of them, can easily be re-used as a jumping off point for new work. Why solve the same problem twice?

Take something pre-existing, and modify it.

Writing vs. editing mode

A concept I saw fairly recently was splitting up your work into distinct parts: Writing (creating) vs Editing (analysing).

Writers write initial drafts without too many rules in mind. They simply vomit the words onto the paper, continuing to write as the ideas flow.

To break the 4th wall slightly, when writing this post, I won’t look back at a single sentence I’ve written until the very end, when I go back through it. If I try (and I have done in the past) and edit as I go, I find it a hugely jarring process. It’s like I’m conflicting two ideals and motivations.

Never half-ass two things. Whole-ass one thing. —Ron Swanson

Judd Apatow and The Big Sick

This is going to be purely anecdotal, because I can’t find a link to where I heard it, but when Kumail Nanjiani was writing The Big Sick (its great; watch it), Judd Apatow (producer) told Kumail to write the first draft as if no-one was going to read it. Just, dump it all down on paper, every detail, don’t try and confine it to a movie script, or a screenplay.

I think the takeaway here is to just get everything out of you, onto paper/a code editor. It can be fixed up later, separately.

First do it, then do it right, then do it better - this is my mantra for successfully getting things done. It's all about the iteration. —Addy Osmani